withCredentials在跨域发送cookie时的应用-创新互联

服务A：http://192.168.126.129:5001
服务B：http://192.168.126.129:5002或者任意一个请求A时是跨域的地址

现在服务A有了它自己的cookie，我们在服务B通过ajax访问服务A或者与A同域的任何一个服务（如http://192.168.126.129:8002，http://192.168.126.129:8003....等）时，是一种跨域访问方式，默认情况下A的cookie是不会随带发的，要想这些服务端（A或者与A同域的服务端）接收到这些cookie，仅仅需要发送时设置ajax：
withCredentials=true
这样服务端就能收到这些cookie了，事情告一段落了。

注意：假设服务A有个签发cookie的服务，服务B ajax跨域调用A的这个服务来设置A的cookie，此时要想Set-Cookie生效，B调用时也要带上withCredentials=true，否则不能保存cookie

但是这个时候服务端A对这个跨域的ajax请求的响应，浏览器默认是不会接受的，因为跨域了，
此时A服务端需要做如下设置：
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin：（B的协议:域名+端口，.net core的CORS中间件也可以写个*号）
缺一不可，注意这仅仅是为了浏览器能接收这个请求的响应，不设置，不会阻止请求和cookie的发送！！！

注意：
上面说的只对ajax请求有效。如果B系统有个链接指向A系统，那么点击这个链接，cookie默认还是会发过去的，这就是很多csrf威胁的根源。要想避免这种情况，可设置A的cookie的SameSite属性：
none：不做任何阻止，这是默认值
Strict：阻止任何从A系统外的地方访问A系统时带A的cookie，有效阻止CSRF威胁
Lax： 只会在使用危险HTTP方法或异步请求（比如script，img，link，iframe，表单发起的post请求）发送跨域cookie的时候进 行阻止，其他同步请求（打开新窗口，改变当前页面的get请求）不会被阻止，一般的cookie可以设置为strict，会话cookie为了好的体验，建议设为Lax，这个时候A系统的服务最好保证Get请求仅仅是读取类的请求。

另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。