头几天在帮后端排查一个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
