假設有如下兩個服務：
服務A：//192.168.126.129:5001
服務B：//192.168.126.129:5002或者任意一個請求A時是跨域的地址
現在服務A有了它自己的cookie，我們在服務B通過ajax訪問服務A或者與A同域的任何一個服務（如//192.168.126.129:8002，//192.168.126.129:8003....等）時，是一種跨域訪問方式，默認情況下A的cookie是不會隨帶發的，要想這些服務端（A或者與A同域的服務端）接收到這些cookie，僅僅需要發送時設置ajax：
withCredentials=true
這樣服務端就能收到這些cookie了，事情告一段落了。
但是這個時候服務端A對這個跨域的ajax請求的響應，瀏覽器默認是不會接受的，因為跨域了，此時A服務端需要做如下設置：
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin：（B的協議:域名+端口，.net core的CORS中間件也可以寫個*號）
缺一不可，注意這僅僅是為了瀏覽器能接收這個請求的響應，不代表服務器沒發送響應，不設置，不會阻止請求和cookie的發送！！！
現在假設服務A有個簽發cookie的服務，服務B ajax跨域調用A的這個服務來設置A的cookie，此時要想Set-Cookie生效，B調用時也要帶上withCredentials=true，否則不能保存cookie（只是瀏覽器不能保存而已，set-Cookie頭還是傳到瀏覽器端來了的）；另外，如果服務A這個服務是非https的，瀏覽器可能會提示：
解決方案：服務A采用https，同時簽發的cookie設置：Secure; SameSite=None
注意：上面說的只對ajax請求有效。如果B系統有個鏈接指向A系統，那么點擊這個鏈接，cookie默認還是會發過去的，這就是很多csrf攻擊的根源。要想避免這種情況，可設置A的cookie的SameSite屬性，SameSite的取值有如下幾種情況：
none：不做任何阻止，這是某些瀏覽器的默認值
Strict：阻止任何從A系統外的地方訪問A系統時帶A的cookie，有效阻止CSRF攻擊
Lax： Lax規則稍稍放寬，大多數情況也是不發送第三方 Cookie，但是導航到目標網址的 Get 請求除外
導航到目標網址的 GET 請求，只包括三種情況：鏈接，預加載請求，GET 表單。詳見下表：
設置了Strict或Lax以后，基本就杜絕了 CSRF 攻擊。當然，前提是用戶瀏覽器支持 SameSite 屬性。
Chrome 計劃將Lax變為默認設置。這時，網站可以選擇顯式關閉SameSite屬性，將其設為None。 不過，前提是必須同時設置Secure屬性（Cookie 只能通過 HTTPS 協議發送），否則無效。下面的設置無效。 Set-Cookie: widget_session=abc123; SameSite=None 下面的設置有效。 Set-Cookie: widget_session=abc123; SameSite=None; Secure
以上是個人通過實際操作總結而出，不當之處，歡迎留言。
