withCredentials在跨域發(fā)送cookie時的應(yīng)用

服務(wù)A：http://192.168.126.129:5001
服務(wù)B：http://192.168.126.129:5002或者任意一個請求A時是跨域的地址

現(xiàn)在服務(wù)A有了它自己的cookie，我們在服務(wù)B通過ajax訪問服務(wù)A或者與A同域的任何一個服務(wù)（如http://192.168.126.129:8002，http://192.168.126.129:8003....等）時，是一種跨域訪問方式，默認(rèn)情況下A的cookie是不會隨帶發(fā)的，要想這些服務(wù)端（A或者與A同域的服務(wù)端）接收到這些cookie，僅僅需要發(fā)送時設(shè)置ajax：
withCredentials=true
這樣服務(wù)端就能收到這些cookie了，事情告一段落了。

注意：假設(shè)服務(wù)A有個簽發(fā)cookie的服務(wù)，服務(wù)B ajax跨域調(diào)用A的這個服務(wù)來設(shè)置A的cookie，此時要想Set-Cookie生效，B調(diào)用時也要帶上withCredentials=true，否則不能保存cookie

但是這個時候服務(wù)端A對這個跨域的ajax請求的響應(yīng)，瀏覽器默認(rèn)是不會接受的，因?yàn)榭缬蛄耍?br/>此時A服務(wù)端需要做如下設(shè)置：
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin：（B的協(xié)議:域名+端口，.net core的CORS中間件也可以寫個*號）
缺一不可，注意這僅僅是為了瀏覽器能接收這個請求的響應(yīng)，不設(shè)置，不會阻止請求和cookie的發(fā)送?。。?/p>

注意：
上面說的只對ajax請求有效。如果B系統(tǒng)有個鏈接指向A系統(tǒng)，那么點(diǎn)擊這個鏈接，cookie默認(rèn)還是會發(fā)過去的，這就是很多csrf威脅的根源。要想避免這種情況，可設(shè)置A的cookie的SameSite屬性：
none：不做任何阻止，這是默認(rèn)值
Strict：阻止任何從A系統(tǒng)外的地方訪問A系統(tǒng)時帶A的cookie，有效阻止CSRF威脅
Lax： 只會在使用危險HTTP方法或異步請求（比如script，img，link，iframe，表單發(fā)起的post請求）發(fā)送跨域cookie的時候進(jìn) 行阻止，其他同步請求（打開新窗口，改變當(dāng)前頁面的get請求）不會被阻止，一般的cookie可以設(shè)置為strict，會話cookie為了好的體驗(yàn)，建議設(shè)為Lax，這個時候A系統(tǒng)的服務(wù)最好保證Get請求僅僅是讀取類的請求。