In the process of developing a web front-end and back-end of the FBI, I encountered a problem:
Access to XMLHttpRequest at 'xxx' from origin 'yyy' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the rquested resource.
Literally means to Http request from the Y domain backstage X domain, but the first Http request feedback resource is not included in 'Access-Control-Allow-Origin' content, what does that mean?
CORS mean cross-domain resource sharing, when from a web server itself does not belong where resources address (domain name, protocol, port) requests a resource, it will initiate such a cross-domain HTTP requests, such as your domain name where the service is ' www.aaa.com/yyy ', this time you want the front end from ' www.bbb.com/xxx ' request for a resource, it will trigger a cross-domain requests. For security reasons, the browser will restrict such cross-domain request, unless the response packet contains the correct CORS response headers .
So I have encountered such a browser error, prompt response message returned my head needs not included in the response, which is 'Access-Control-Allow-Origin'.
To solve this problem is very simple, first of all ensure that your background can indeed received a request front-end (to avoid being intercepted by a gateway, etc., rather than CORS problem, but if reported out such a mistake, because the basic problem is the response headers ), and then return the response header plus 'Access-Control-Allow-Origin', the corresponding value that should be what is it? It is actually a value corresponding to the requested content packet header 'Origin' field. Therefore, to determine what Origin field of the request to the front of your butt is, adding the response header to go in, as follows:
Request Headers:
Request URL: http://www.bbb.com/xxx
Request Method: POST
Remote Address: 127.0.0.1:12345
Referrer Policy: no-referrer-when-downgrade
Accept: application/json, text/plain, /
Authorization: Basic Y2xvdWRveG91Og==
Content-Type: application/json; charset=UTF-8
Origin: http://www.aaa.com
Referer: http://www.aaa.com/yyy
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36Response Headers:
Access-Control-Allow-Origin: http://www.aaa.com
Connection: keep-alive
Content-Disposition: attachment;filename=abc.csv
Content-Length: 301
Content-Type: application/octet-stream
Date: Sun, 26 May 2019 08:31:33 GMT
X-Cache: MISS from SK-SQUIDWEB-72
X-Cache-Lookup: MISS from SK-SQUIDWEB-72:8080
Can be seen from the above examples, there is a field in the request header Origin, and the response header is added a corresponding Access-Control-Allow-Origin field, so that the browser does not intercept the request and returned to smooth visit.
Would have been normal, but later after the front did a little change, there was a similar problem, this is not Access-Control-Allow-Origin of the problem, but it is also similar, in fact, cross-domain requests of control is not just a problem of Origin there are also two fields is related to this:
Access-Control-Allow-Methods 和 Access-Control-Allow-Headers。
If the leading end of the request header increases Access-Control-Request-Method and Access-Control-Request-Headers field, the background must be returned in response contains the above two header fields, to be noted that there is no method distal s, but there is background, why? The front end of a request must be only one way, but the background needed to allow a variety of methods, especially OPTIONS method, in the face of the POST request can make a difference like the data on the server, the front end will be a first default OPTIONS request (preflight request) after authentication will be formally issued a GET or pOST request, so in background processing also need to determine what the current request method is the face OPTIONS, do not return to complete the data, just tell me to accept you on the line. So the real agreement should look like:
Preflight request:
Request Headers:Request URL: http://www.bbb.com/xxx
Request Method: OPTIONS
Remote Address: 127.0.0.1:12345
Referrer Policy: no-referrer-when-downgrade
Accept: application/json, text/plain, /
Authorization: Basic Y2xvdWRveG91Og==
Content-Type: application/json; charset=UTF-8
Origin: http://www.aaa.com
Access-Control-Request-Headers: authorization,content-type
Access-Control-Request-Method: POST
Referer: http://www.aaa.com/yyy
Access-Control-Allow-Origin: http://www.aaa.com
Connection: keep-alive
Content-Disposition: attachment;filename=abc.csv
Content-Length: 301
The Type-the Content: file application / OCTET Stream-
a Date: the Sun, 2019 08:31:33 GMT On May 26 is
X--the Cache: MISS SQUIDWEB from SK-72-
X--the Cache-the Lookup: MISS from SK-72-SQUIDWEB: 8080
from above examples can be seen, there is a request header field Origin, and in response to the added header Access-Control-Allow-Origin corresponding to a field, so that the browser does not intercept the request and returns, it is possible to smoothly Access.
Would have been normal, but later after the front did a little change, there was a similar problem, this is not Access-Control-Allow-Origin of the problem, but it is also similar, in fact, cross-domain requests of control is not just a problem of Origin , there are two fields are associated with this:
Access-Control-Methods and the Allow-Access-Control-Allow-Headers.
If the leading end of the request header increases Access-Control-Request-Method and Access-Control-Request-Headers field, the background must be returned in response contains the above two header fields, to be noted that there is no method distal s, but there is background, why? The front end of a request must be only one way, but the background needed to allow a variety of methods, especially OPTIONS method, in the face of the POST request can make a difference like the data on the server, the front end will be a first default OPTIONS request (preflight request) after authentication will be formally issued a GET or pOST request, so in background processing also need to determine what the current request method is the face OPTIONS, do not return to complete the data, just tell me to accept you on the line. So the real agreement should look like:
> preflight request:
>Request Headers:
>>Request URL: http://www.bbb.com/xxx
Request Method: OPTIONS
Remote Address: 127.0.0.1:12345
Referrer Policy: no-referrer-when-downgrade
Accept: application/json, text/plain, /
Authorization: Basic Y2xvdWRveG91Og==
Content-Type: application/json; charset=UTF-8
Origin: http://www.aaa.com
Access-Control-Request-Headers: authorization,content-type
Access-Control-Request-Method: POST
Referer: http://www.aaa.com/yyy
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36Response Headers:
Access-Control-Allow-Origin: http://www.aaa.com
Access-Control-Allow-Headers: authorization,content-type
Access-Control-Allow-Methods: POST, GET, OPTIONS
Connection: keep-alive
Content-Disposition: attachment;filename=abc.csv
Content-Length: 301
Content-Type: application/octet-stream
Date: Sun, 26 May 2019 08:31:33 GMT
X-Cache: MISS from SK-SQUIDWEB-72
X-Cache-Lookup: MISS from SK-SQUIDWEB-72:8080The actual request
Request Headers:Request URL: http://www.bbb.com/xxx
Request Method: POST
Remote Address: 127.0.0.1:12345
Referrer Policy: no-referrer-when-downgrade
Accept: application/json, text/plain, /
Authorization: Basic Y2xvdWRveG91Og==
Content-Type: application/json; charset=UTF-8
Origin: http://www.aaa.com
Referer: http://www.aaa.com/yyy
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36Response Headers:
Access-Control-Allow-Origin: http://www.aaa.com
Connection: keep-alive
Content-Disposition: attachment;filename=abc.csv
Content-Length: 301
Content-Type: application/octet-stream
Date: Sun, 26 May 2019 08:31:33 GMT
X-Cache: MISS from SK-SQUIDWEB-72
X-Cache-Lookup: MISS from SK-SQUIDWEB-72:8080
Can be seen from the above, the request will go through twice, the first time preflight request OPTIONS method, consulting whether to support the POST method, the second request is true, in the first request includes Origin, Access-Control- Allow-Headers, Access-Control-Allow-Method three inter-request header in the second request in the real, only the Origin field. So as a background, the need for appropriate return:
- For Origin: For security reasons, the white background is best to maintain a list of domain name Origin only the white list, it appears in the Access-Control-Allow-Origin in return, which can effectively prevent malicious Web site to obtain or modify other data.
- For Access-Control-Allow-Headers: Since the contents of which carries the front end of uncertainty, the front end can obtain the corresponding field contents directly copied to the Access-Control-Allow-Headers field contents returned in response to the head.
- For Access-Control-Allow-Method: based on business scenarios, which method background support, it can be put to, a variety of methods separated by commas.
So far, cross-domain request is fully configured OK, you can normally access it.
Reference:
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS