基本認知

以下討論都是在瀏覽器上的限制，如果是自己寫程式，或postman，服務間的呼叫都不受限，這是初學者可能會忘了的一點

不同源的網站資源要在同源限制下互相利用

目的

從第一篇同源的限制可知道，主要限制的是js的write/embed/read，故cors主要就是在特定條件下，讓瀏覽器知道這是可信任的操作

如何做到?

透過在resp header加上訊息讓瀏覽器做判斷，在後端來做或webserver添加都可以，但只能擇一

簡單請求simple requests

HEAD、GET、POST 方法其中之一
HTTP 的 header 限制為： Accept Accept-Language Content-Language Last-Event-ID Content-Type 只能是 application/x-www-form-urlencoded、multipart/form-data、text/plain

方式

添加一個resp header

Access-Control-Allow-Origin

非簡單請求

超過上述的限制後，瀏覽器在真正請求前，會打預請求preflight request，來判斷真正請求是否發出，所以會依序送出兩種請求

preflight的方法是OPTIONS

非簡單請求常見的方法是PUT,DELETE

方式

添加三個resp header

Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers

以下是常見的老舊範例XD

在設定上分為前端，原本後端，跨站的後端

<前端:> fetch=>credentials: “include” axios=>withCredentials: true

<原本後端:> 在Chrome 80之後要設定same site=None + 掛https

<跨站的後端:> Access-Control-Allow-Credentials = true

CorsDemo

工作上遇到問題，發現cors請求已經通過，但是在cors cookie上，Chrome帶不上去，所以寫一個小專案來檢查問題 https://github.com/hanksky12/CorsPratices

後來發現即使是這個原形專案，cookie還是無法從Chrome帶到跨站的後端，2024以前滿足上面的條件就能帶上cookie，但2024開始Chrome逐漸禁用第三方cookie，而我剛好是前幾批次被挑中的人，所以我的browser已經無法帶第三方cookie，簡單的說就是換了一種更嚴格的方式來實作cors cookie

後來去思考為何第三方cookie，越來越難實作，我覺得根本性原因是同公司的網站，本來去採用同一個網域去面對瀏覽器才是合理的配置，故自己最後選擇用nginx來反向代理所有後端，讓瀏覽器面對單一網域也簡化了問題

2024之後實作cors cookie，需要到google chrome github，提交自己的原站與跨域站，發PR讓他們做審核通過

https://developers.google.com/privacy-sandbox/3pcd/related-website-sets?fbclid=IwAR21Uy23UfmxMoQ6ZbXgeW9qHeWOYFc-_lQQBB3Pj_vWK34ASz8FHVIaATg

https://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md?fbclid=IwAR3-kQAUCaKNF-VVWEXE0_vyVTUcZ4oo4djZdQpICo7cp4OfGfs0sFkpbqI