#flask #cors #swagger-ui #flask-cors
Вопрос:
У меня есть swagger (докер: swaggerapi/swagger-ui), работающий на swagger.mydomain.com с двумя определениями для серверов api, работающих на a.mydomain.com и b.mydomain.com
И a, и b являются серверами flask (python). a.mydomain.com некоторое время назад был настроен CORS из-за обслуживания веб-приложения на четвертом поддомене. Это отлично работает как на этом поддомене, так и в swagger. Теперь я сделал ту же настройку CORS для b.mydomain.com, однако безуспешно.
Настройка на обоих серверах выглядит следующим образом:
from flask import Flask
from flask_cors import CORS
app = Flask(__name__)
CORS(app, origins=r"^.*(mydomain.com)")
Как я уже сказал, это работает на a.mydomain.com, но не на b.mydomain.com.
Предварительный просмотр выглядит идентично, за исключением URL-адресов, кода состояния (200 и 400 соответственно), а также того, что рабочий запрос имеет дополнительный allow: POST, OPTIONS заголовок. Я не вижу никакой разницы в коде, чтобы оправдать этот дополнительный заголовок.
Неудачный предполетный запрос занимает 150 мс, что вдвое больше рабочего запроса.
Выполнение запроса через swagger обеспечивает запрос curl. Выполнение этого локально дает ожидаемый результат, поэтому запрос в целом верен.
Я понятия не имею, что еще попробовать. Насколько я могу судить, а и b.mydomain.com настроены точно так же. Что здесь может быть не так?
Ответ №1:
400 — довольно необычный код ответа для предполетного ответа. Это предполагает, что конечная точка может быть настроена на ожидание определенного тела запроса/полезной нагрузки или заголовков в запросе независимо от того, какой метод HTTP используется для запроса. Но поскольку для предполетного OPTIONS запроса браузер не отправляет тело запроса и дополнительный заголовок, серверный код получает не то, что он ожидает.
В таких случаях исправление состоит в том, чтобы убедиться, что у вас есть отдельный обработчик OPTIONS запросов, настроенный для этого маршрута/конечной точки.