HTTP跨域请求后台处理

2021-11-23 14:53:57 浏览数 (1)

在开发web后台与前端联调的过程中,遇到了一个问题:

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.

字面意思就是从Y域中去Http请求X域的后台,但是请求反馈的资源的Http头中没有包含'Access-Control-Allow-Origin'内容,什么意思呢?

CORS的意思是跨域资源共享,当web从一个不属于本身所在的服务器的资源地址(域名、协议、端口)请求资源时,就会发起这样一个跨域HTTP请求,比如你的服务所在域名是‘www.aaa.com/yyy’,这时候你的前端想要从‘www.bbb.com/xxx’请求一个资源,就会触发跨域请求。处于安全原因,浏览器会限制这样的跨域请求,除非响应报文中包含了正确的CORS响应头

因此我就遇到了这样的浏览器报错,提示我返回的响应报文中没有包含需要的响应头,也就是'Access-Control-Allow-Origin'。

要解决这个问题也很简单,首先保证你的后台能够确实地接收到前端的请求(以防被网关等拦截,而非CORS问题,但如果报出了这样的错误,基本是因为响应头的问题),然后再返回的响应头中加上'Access-Control-Allow-Origin',那对应的值应该是什么呢?对应的值其实就是请求报文头中的‘Origin’字段的内容。所以,确定你要对接的前端的请求的Origin字段是什么,在响应头中添加进去即可,如下:

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.36 Response 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

从上面的例子可以看到,在请求头中有一个Origin字段,而在响应头中则加了一个对应的Access-Control-Allow-Origin字段,这样浏览器就不会拦截请求和返回了,从而能够顺利的访问。

本来正常了,但后来前端做了一点变化后,又出现了类似的问题,这次不是Access-Control-Allow-Origin的问题了,但也是类似的,其实跨域请求的控制不只是Origin的问题,还有两个字段也是与此相关的:

Access-Control-Allow-Methods 和 Access-Control-Allow-Headers。

前端的请求头中如果增加了 Access-Control-Request-Method 和 Access-Control-Request-Headers 字段,那么后台返回的响应头也必须包含上面两个字段,要注意method前端没有s,但后台有,为什么?前端一次请求必定只有一种方法,但后台需要允许多种方法,尤其是OPTIONS方法,面对POST之类的可能对服务器数据产生变化的请求,前端会默认先进行一次OPTIONS请求(预检请求),验证通过后才会正式发出GET或者POST请求,所以在后台处理时也需要判断当前的请求方法是什么,面对OPTIONS,就不要返回完整的数据了,只需要告知我接受你就行了。所以真实的协议应该类似:

预检请求: 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.36 Response 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:8080 实际请求 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.36 Response 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

从上面可以看出来,会经历两次请求,第一次OPTIONS方法的预检请求,咨询是否支持POST方法,第二次才是真实请求,在第一次请求中,包含 Origin、Access-Control-Allow-Headers、Access-Control-Allow-Method 三种跨域请求头,在第二次真实请求中,就只有Origin字段了。所以作为后台,需要进行相应的返回:

  • 对于Origin:出于安全考虑,后台最好维护一份白名单,只有白名单中的域名Origin,才出现在Access-Control-Allow-Origin中返回,这样可以有效避免其他恶意网站获取或者修改数据。
  • 对于Access-Control-Allow-Headers:由于不确定前端会携带何种内容,可以直接获取前端的相应字段内容,复制到返回的响应头的Access-Control-Allow-Headers字段内容中即可。
  • 对于Access-Control-Allow-Method:根据业务场景,后台支持何种方法,就放进去即可,逗号隔开多种方法。

至此,跨域请求就完全配置OK,可以正常访问啦。

参考资料: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

0 人点赞