Best method: Access-Control-Allow-Origin Multiple Origin Domains

后端 未结 2 2023
迷失自我
迷失自我 2021-02-03 21:27

This question has been asked on here before and given an array of good answers, mainly: Access-Control-Allow-Origin Multiple Origin Domains?

However there seems to be a

2条回答
  •  无人及你
    2021-02-03 21:45

    The documentation on this seems to imply that it allows multiple origins with a space separated list, but that's not what it actually means. Here's what I could gather as the most definitive answer to your question: the Access-Control-Allow-Origin header should be the same value as the Origin header as long as you want to allow it.

    The reason it's not a whitelist that you send back to the client is because technically the client can send a space separated list of origins so that the server can validate the request. The purpose of origin list then is because the request could've come from multiple origins (ie. the request was redirected across domains). A test suite makes it easy to observe this behavior with varying redirect possibilities, even though a space separated list is never generated (by Firefox at least).

    This is illustrated lower in the first linked W3C document you provided:

    The Access-Control-Allow-Origin header indicates whether a resource can be shared based by returning the value of the Origin request header, "*", or "null" in the response. ABNF:

    Access-Control-Allow-Origin = "Access-Control-Allow-Origin" ":" origin-list-or-null | "*"

    In practice the origin-list-or-null production is more constrained. Rather than allowing a space-separated list of origins, it is either a single origin or the string "null".

    And again in the definition of the origin list. In addition it shows if you do want to allow the string "null" as an origin, it wouldn't be able to be embedded in an origin list anyways.

    So stick with the dynamically generated header based on the client's Origin header and whether that matches your whitelist.

提交回复
热议问题