Tengo swagger (docker: swaggerapi/swagger-ui) ejecutándose en swagger.mydomain.com con dos definiciones para servidores API que se ejecutan en a.mydomain.com y b.mydomain.com
Tanto a como b son servidores de matraz (python). a.mydomain.com tenía CORS configurado desde hace un tiempo debido a que sirve una aplicación web en un cuarto subdominio. Esto funciona bien tanto en ese subdominio como en swagger. Ahora hice la misma configuración de CORS para b.mydomain.com, sin embargo, sin éxito.
La configuración en ambos servidores se ve así:
from flask import Flask from flask_cors import CORS app = Flask(__name__) CORS(app, origins=r"^.*(mydomain\.com)")Como dije, esto funciona en a.mydomain.com, pero no en b.mydomain.com.
Preflight se ve idéntico, excepto las direcciones URL, el código de estado (200 y 400 respectivamente), así como que la solicitud de trabajo tiene un allow: POST, OPTIONS . No veo ninguna diferencia en el código para justificar este encabezado adicional.
La solicitud de verificación previa fallida tarda 150 ms, que es el doble de la solicitud de trabajo.
Ejecutar una solicitud a través de swagger proporciona una solicitud curl. Ejecutar esto localmente da el resultado esperado, por lo que la solicitud generalmente es correcta.
No tengo idea de qué más probar. Por lo que puedo ver, a y b.mydomain.com están configurados exactamente igual. ¿Qué podría estar mal aquí?
Un 400 es un código de respuesta bastante inusual para una respuesta previa al vuelo. Eso sugiere que el punto final podría configurarse para esperar un determinado cuerpo/carga útil o encabezados de solicitud en la solicitud, independientemente del método HTTP para la solicitud. Pero dado que para la solicitud de OPTIONS de verificación previa, el navegador no envía ningún cuerpo de solicitud ni encabezado adicional, el código del servidor no recibe lo que espera.
Para tales casos, la solución es asegurarse de tener un controlador específico e independiente para las solicitudes de OPTIONS configuradas para esa ruta/punto final.