Access-Control-Allow-Origin标头如何工作? [英] How does Access-Control-Allow-Origin header work?
问题描述
显然,我完全误解了它的语义。我想到这样的东西:
- 客户端从http:// siteA - / strong>。
- MyCode.js的响应标头包含 Access-Control-Allow-Origin:http:// siteB ,我认为这意味着MyCode .js允许对站点B进行跨源引用。
- 客户端触发了MyCode.js的某些功能,后者又向http:// siteB发送请求
好吧,我错了。它不工作像这样的。因此,我阅读了跨源资源共享,并尝试阅读 w3c推荐中的跨源资源共享
有一件事是肯定的 - 我还是不明白我应该使用这个标题。
我完全控制了网站A和网站B.如何启用从网站A下载的JavaScript代码以使用此标头访问网站B上的资源?
PS
我不想使用JSONP。
Access-Control-Allow-Origin
是一个 CORS(跨源资源共享)头。
当站点A尝试获取内容从站点B,站点B可以发送访问控制允许原始
响应头以告诉浏览器该页面的内容对某些来源可访问。 ( 是网域,以及计划和端口号。)默认情况下,网站B的网页是无法访问任何其他来源;使用 Access-Control-Allow-Origin
标题打开了通过特定请求来源的跨源访问的门。
对于网站B想要访问网站A的每个资源/页面,网站B应向其页面提供响应标头:
Access-Control-Allow-Origin:http://siteA.com
现代浏览器直接阻止跨域请求。如果站点A请求来自站点B的页面,则浏览器实际上将在网络层面上获取所请求的页面并检查响应首标是否将站点A列为允许的请求者域。如果网站B没有指明网站A被允许访问此网页,浏览器将触发 XMLHttpRequest
的错误
- 使用非简单的请求标头;只有简单的请求标头是:
-
接受
-
Accept-Language
-
Content-Language
-
Content-Type
(只有当值application / x-www-form-urlencoded
,multipart / form-data
或text / plain
)
-
如果服务器使用适当的响应标头响应OPTIONS preflight( Access-Control-Allow-Headers
用于非简单标题, Access-Control-Allow-Methods
用于非简单动词),匹配非简单动词和/
假设网站A想要发送 / somePage $ c的PUT请求$ c>,使用非简单的
Content-Type
值 application / json
,浏览器首先会发送预检请求:
选项/ somePage HTTP / 1.1
原产地:http://siteA.com
访问控制请求方法:PUT
访问控制请求头:内容类型
请注意, Access-Control-Request-Method
和 Access-Control-Request-Headers
浏览器自动;您不需要添加它们。此OPTIONS预检获取成功的响应标头:
访问控制允许原产地:http://siteA.com
Access-Control-Allow-Methods:GET,POST,PUT
Access-Control-Allow-Headers:Content-Type
发送实际请求时(预检后),行为与处理简单请求的方式相同。换句话说,其预检成功的非简单请求被视为与简单请求相同(即,服务器必须再次发送 Access-Control-Allow-Origin
<$ c $ c> PUT / somePage HTTP / 1.1
原产地:http://siteA.com
Content-Type:application / json
{myRequestContent:JSON is so great }
服务器发送一个 Access-Control-Allow-Origin
,就像为一个简单的请求:
Access-Control-Allow-Origin:http ://siteA.com
请参阅了解关于CORS的XMLHttpRequest 了解有关非简单请求的一些详细信息。
Apparently, I have completely misunderstood its semantics. I thought of something like this:
- A client downloads javascript code MyCode.js from http://siteA - the origin.
- The response header of MyCode.js contains Access-Control-Allow-Origin: http://siteB, which I thought meant that MyCode.js was allowed to make cross-origin references to the site B.
- The client triggers some functionality of MyCode.js, which in turn make requests to http://siteB, which should be fine, despite being cross-origin requests.
Well, I am wrong. It does not work like this at all. So, I have read Cross-origin resource sharing and attempted to read Cross-Origin Resource Sharing in w3c recommendation
One thing is sure - I still do not understand how am I supposed to use this header.
I have full control of both site A and site B. How do I enable the javascript code downloaded from the site A to access resources on the site B using this header?
P.S.
I do not want to utilize JSONP.
Access-Control-Allow-Origin
is a CORS (Cross-Origin Resource Sharing) header.
When Site A tries to fetch content from Site B, Site B can send an Access-Control-Allow-Origin
response header to tell the browser that the content of this page is accessible to certain origins. (An origin is a domain, plus a scheme and port number.) By default, Site B's pages are not accessible to any other origin; using the Access-Control-Allow-Origin
header opens a door for cross-origin access by specific requesting origins.
For each resource/page that Site B wants to make accessible to Site A, Site B should serve its pages with the response header:
Access-Control-Allow-Origin: http://siteA.com
Modern browsers will not block cross-domain requests outright. If Site A requests a page from Site B, the browser will actually fetch the requested page on the network level and check if the response headers list Site A as a permitted requester domain. If Site B has not indicated that Site A is allowed to access this page, the browser will trigger the XMLHttpRequest
's error
event and deny the response data to the requesting JavaScript code.
Non-simple requests
What happens on the network level can be slightly more complex than explained above. If the request is a "non-simple" request, the browser first sends a data-less "preflight" OPTIONS request, to verify that the server will accept the request. A request is non-simple when either (or both):
- using an HTTP verb other than GET or POST (e.g. PUT, DELETE)
- using non-simple request headers; the only simple requests headers are:
Accept
Accept-Language
Content-Language
Content-Type
(this is only simple when its value isapplication/x-www-form-urlencoded
,multipart/form-data
, ortext/plain
)
If the server responds to the OPTIONS preflight with appropriate response headers (Access-Control-Allow-Headers
for non-simple headers, Access-Control-Allow-Methods
for non-simple verbs) that match the non-simple verb and/or non-simple headers, then the browser sends the actual request.
Supposing that Site A wants to send a PUT request for /somePage
, with a non-simple Content-Type
value of application/json
, the browser would first send a preflight request:
OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type
Note that Access-Control-Request-Method
and Access-Control-Request-Headers
are added by the browser automatically; you do not need to add them. This OPTIONS preflight gets the successful response headers:
Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type
When sending the actual request (after preflight is done), the behavior is identical to how a simple request is handled. In other words, a non-simple request whose preflight is successful is treated the same as a simple request (i.e., the server must still send Access-Control-Allow-Origin
again for the actual response).
The browsers sends the actual request:
PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json
{ "myRequestContent": "JSON is so great" }
And the server sends back an Access-Control-Allow-Origin
, just as it would for a simple request:
Access-Control-Allow-Origin: http://siteA.com
See Understanding XMLHttpRequest over CORS for a little more information about non-simple requests.
这篇关于Access-Control-Allow-Origin标头如何工作?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!