When you test the request with curl (and use -v or -I to show the response headers) - are you seeing the Access-Control-Allow-Origin header in the api response? One complication, and a reason that adding the header to the response might not have work correctly the first time doing the obvious thing, is that Chrome is sending an HTTP OPTIONS request, rather than a GET to your route, and it's checking the headers there (if it only checked the response headers after sending the first request, that would defeat the purpose of the cross origin protection, only blocking subsequent follow-up requests, but letting the first one through). If you are only setting the cors header in your app's defined routes for the GET/POST requests, rather than globally, that can cause your local curl/postman tests to succeed since they aren't checking CORS, but your browser requests to fail (chrome will check).
A test like this would make the most sense to confirm you are seeing the header you expect:
# the GET request your browser is asking for:
curl -I http://localhost:5000/api/v1/register
# preflight check is an OPTIONS request, not GET, # chrome sends this first, then the GET
curl -I-X OPTIONS http://localhost:5000/api/v1/register
In a quick sample test (I tried the simplest xhr request example from a browser to confirm), the flask-cors module looks like it added the headers to all responses from the app (not just specific routes). Effectively this was what I did to get both the options and the get requests to return the correct header:
# you probably import flask or parts of it, add flask_cors next
fromflask_corsimportCORS,cross_origin# create the server app, you likely have something like this
app=Flask(__name__)# attach the CORS wrapper to the app
CORS(app,supports_credentials=True)# the rest of your flask code, like @app.route(...)
When I added that it changed the response headers from the base
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 22
Server: Werkzeug/2.0.3 Python/3.9.2
Date: Mon, 07 Feb 2022 23:38:37 GMT
To a slightly more useful case
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 22
Access-Control-Allow-Origin: *
Server: Werkzeug/2.0.3 Python/3.9.2
Date: Mon, 07 Feb 2022 23:40:20 GMT
The options response looked like this (there's no body in the options response, so you only get headers):
When you test the request with curl (and use -v or -I to show the response headers) - are you seeing the Access-Control-Allow-Origin header in the api response? One complication, and a reason that adding the header to the response might not have work correctly the first time doing the obvious thing, is that Chrome is sending an HTTP OPTIONS request, rather than a GET to your route, and it's checking the headers there (if it only checked the response headers after sending the first request, that would defeat the purpose of the cross origin protection, only blocking subsequent follow-up requests, but letting the first one through). If you are only setting the cors header in your app's defined routes for the GET/POST requests, rather than globally, that can cause your local curl/postman tests to succeed since they aren't checking CORS, but your browser requests to fail (chrome will check).
A test like this would make the most sense to confirm you are seeing the header you expect:
In a quick sample test (I tried the simplest xhr request example from a browser to confirm), the flask-cors module looks like it added the headers to all responses from the app (not just specific routes). Effectively this was what I did to get both the options and the get requests to return the correct header:
When I added that it changed the response headers from the base
To a slightly more useful case
The options response looked like this (there's no body in the options response, so you only get headers):
Hope this helps.