HTTP访问控制(CORS)踩坑小记

coding

前几天在帮后端排查一个cors的问题的时候发现的一些小坑特此记录

**

cors的本质是出于安全原因,浏览器限制从脚本内发起的跨源HTTP请求。 例如,XMLHttpRequest和Fetch


API遵循同源策略。 这意味着使用这些API的Web应用程序只能从加载应用程序的同一个域请求HTTP资源,除非使用CORS头文件。


跨域并非一定是浏览器限制了跨站请求,也有可能是跨站请求可以正常发起,但是返回结果被浏览器拦截了。最好的例子是 CSRF


跨站攻击原理,请求是发送到了后端服务器无论是否跨域!注意:有些浏览器不允许从 HTTPS 的域跨域访问 HTTP,比如 Chrome 和


Firefox,这些浏览器在请求还未发出的时候就会拦截请求。

**

本case场景描述如下:
用户在a.com域名下跨域访问b.com域名下的api接口,使用了XMLHttpRequest的跨域头请求。域名b.com也允许了可以跨域 Access-Control-Allow-Origin 但是很奇怪在访问b.com的接口时有些api能访问成功,有些api访问失败。排查发现访问失败的api都是需要用户的登录态的。但是用户已经在b.com登录过了。把XMLHttpRequest请求换成jsonp请求则都可以请求成功(这好像是废话)。。。由此推测XMLHttpRequest 添加cors头的时候没有把b.com的 用户cookie信息带过去。

翻看MDN文档https://developer.mozilla.org... 找到答案如下:

Fetch 与 CORS 的一个的特性是,可以基于 HTTP cookies 和 HTTP 认证信息发送身份凭证。一般而言,对于跨域 XMLHttpRequest 或 Fetch 请求,浏览器不会发送身份凭证信息。如果要发送凭证信息,需要设置 XMLHttpRequest 的某个特殊标志位。

var invocation = new XMLHttpRequest();

var url = 'http://bar.other/resources/credentialed-content/';

function callOtherDomain(){

if(invocation) {

invocation.open('GET', url, true);

invocation.withCredentials = true;//这个是重点

invocation.onreadystatechange = handler;

invocation.send();

}

}

将 XMLHttpRequest 的 withCredentials 标志设置为 true,从而向服务器发送 Cookies。服务器端的响应需要携带 Access-Control-Allow-Credentials: true ,浏览器才会把响应内容返回给请求的发送者。

另外需要注意的是
对于附带身份凭证的请求,服务器不得设置 Access-Control-Allow-Origin 的值为“”。 这是因为请求的首部中携带了 Cookie 信息,如果 Access-Control-Allow-Origin 的值为“”,请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 http://foo.example,则请求将成功执行。

tips:
在跨域访问时,XMLHttpRequest对象的getResponseHeader()方法只能拿到一些最基本的响应头,Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma,如果要访问其他头,则需要服务器设置本响应头Access-Control-Expose-Headers 头让服务器把允许浏览器访问的头放入白名单,例如:

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

其他详细信息见我的博客

以上是 HTTP访问控制(CORS)踩坑小记 的全部内容, 来源链接: utcz.com/z/510138.html

回到顶部