Fix multiple Access-Control-Allow-Origin

[dokime7]

When we use a list of origins like : CORS(app, origins=['http://example.com', 'http://example2.com']) only the first origin is sent to header Access-Control-Allow-Origin The werkzeug.datastructures.MultiDict.items() needs multi=True in order to keep all values.

[corydolphin]

Dokime, this looks great. Is there any chance you have time to add a unit test to verify this behavior? If you can do that, I will release this ASAP. Otherwise it'll take a little longer for me to add a unit test to verify we do not regress on this behavior.

Thanks for the contribution, I really appreciate it!

[dokime7]

I am really sorry but I will not have time to add unit tests. Just check in the test that the Access-Control-Allow-Origin header is present several times in the response. I hope I have not broken anything. Thanks

[corydolphin]

Hi Dokime,

I just double checked the spec, and I believe that the current behavior is more correct, and compliant with the spec.

Resources that wish to enable themselves to be shared with multiple Origins but do not respond uniformly with "*" must in practice generate the Access-Control-Allow-Origin header dynamically in response to every request they wish to allow. As a consequence, authors of such resources should send a Vary: Origin HTTP header or provide other appropriate control directives to prevent caching of such responses, which may be inaccurate if re-used across-origins.

If you specify multiple origins, the Vary header will be sent, and the matching origin (if any) will be returned. If there is no specified Origin header, and 'always_send' is True, then we send the full list of Origin headers.

Can you describe in more detail why you want to have multiple headers returned?

[dokime7]

You must right, I didn't know that the Access-Control-Allow-Origin header value was choosed accordinatly with the Origin header... I did have a CORS problem with a mobile developmennt platform and I guess now that it didn't send Origin header correctly. So, I will make some tests and I think that you can reject my PR, I'm sorry.

[ghost]

Hey, is it working ?

[corydolphin]

Hi Walter,

As per the spec we send back the matching origin, plus the Vary header if there are multiple (which allows intermediate caches to correct cache). Only in the case of an OPTIONS request do we send back the full list.

I believe this is the most correct behavior, both in terms of the spec and practical usage. What issue are you running into that you feel is related? Happy to look and see!

Thanks, Cory

On Mon, Sep 17, 2018 at 10:39 PM Walter notifications@github.com wrote:

Hey, is it working ?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/corydolphin/flask-cors/pull/229#issuecomment-422261792, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbRqX9NkOR2hyepZkhlRRKcvtGMGAXEks5ucIcSgaJpZM4VHZUl .

[ghost]

Hey, Cory.

I have three apis on aws and one web application locally. When I try to get recourses from the apis I receive this error : Failed to load ... compute.amazonaws.com:6001/user/login : Response to preflight request doesn't pass access control check : No ' Access-Control-Allow-Origin ' header is present on the requested resource. Origin ' ... .compute.amazonaws.com ' is therefore not allowed access.

I have registered cors on my blueprints these ways :

1. CORS(oauth, origins=['127.0.0.1:8080/*', '127.0.0.1:5500/*', '...compute.amazonaws.com:6002/*', '...compute.amazonaws.com:6001/*', '...compute.amazonaws.com:6000/*', '*' ...])

2. CORS(oauth)

3. CORS(oauth, resources={r'/*': {'origins': '*'}})

But I still receiving the error.

Obs : I did also try these tips