Issue
I have swagger (docker: swaggerapi/swagger-ui) running on swagger.mydomain.com with two definitions for api servers running on a.mydomain.com and b.mydomain.com
Both a and b are flask (python) servers. a.mydomain.com had CORS set up for a while now due to serving a webapp on a fourth subdomain. This works fine both on that subdomain, as well as in swagger. Now I did the same CORS setup for b.mydomain.com, however without success.
The setup on both servers looks like this:
from flask import Flask
from flask_cors import CORS
app = Flask(__name__)
CORS(app, origins=r"^.*(mydomain\.com)")
As I said, this works on a.mydomain.com, but not on b.mydomain.com.
Preflight looks identical, except the urls, the status code (200 and 400 respectively) as well as that the working request has an additional allow: POST, OPTIONS
header. I don't see any difference in code to justify this additional header.
The failed preflight request takes 150ms which is double of the working request.
Executing a request via swagger provides a curl request. Executing this locally gives the expected output, so the request is generally correct.
I have no idea what else to try. As far as I can see, a and b.mydomain.com are set up exactly the same. What could be wrong here?
Solution
A 400 is a pretty unusual response code for a preflight response. That suggests the endpoint might be configured to expect a certain request body/payload or headers in the request regardless of what the HTTP method is for the request. But since for the preflight OPTIONS
request, the browser sends no request body and no additional header, the server code is not receiving what it expects.
For such cases, the fix is to ensure you have a specific, separate handler for OPTIONS
requests configured for that route/endpoint.
Answered By - sideshowbarker
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.