前言
這篇技術含量比較少一點，來跟大家分享一下寫這系列文的過程以及寫完之後的一些感想。
如果你還沒看這系列文的話，傳送門如下：
這篇技術含量比較少一點，來跟大家分享一下寫這系列文的過程以及寫完之後的一些感想。
如果你還沒看這系列文的話，傳送門如下：
在前面幾篇裡面，我們知道 CORS protocol 基本上就是為了安全性所產生的協定，而除了 CORS 以外，其實還有一系列跟跨來源有關的東西，例如說：
是不是光看到這一系列很類似的名詞就已經頭昏眼花了？對，我也是。在整理這些資料的過程中，發現跨來源相關的安全性問題比我想像中還來得複雜，不過花點時間整理之後發現還是有脈絡可循，因此這篇會以我覺得應該比較好理解的脈絡，去講解為什麼會有這些東西出現。
除了上面這些 COXX 的各種東西，還有其他我想提的跨來源相關安全性問題，也會在這篇一併提到。
在繼續下去之前先提醒一下大家，這篇在講的是「跨來源的安全性問題」，而不單單只是「CORS 的安全性問題」。CORS protocol 所保護的東西跟內容在之前都介紹過了，這篇要談的其實已經有點偏離大標題「CORS」完全手冊，因為這跟 CORS 協定關係不大，而是把層次再往上拉高，談談「跨來源」這件事情。
所以在看底下的東西的時候，不要把它跟 CORS 搞混了。除了待會要講的第一個東西，其他的跟 CORS 關係都不大。
當你獲得了一個知識之後，要怎樣才能知道那是正確的還是錯誤的？在程式的領域中這其實是一個相對簡單的問題，只要去確認規範是怎麼寫的就可以了（如果有規範的話）。
舉例來說，JavaScript 的各種語言特性在 ECMAScript Specification 裡面都找得到，為什麼 [] === [] 會是 false，為什麼 'b' + 'a' + + 'a' + 'a' 會是 baNaNa，這些在規範裡面都有，都會詳細說明是用怎樣的規則在做轉換。
而 Web 相關的領域除了 JS 以外，HTML 或是其他相關的規範幾乎都可以在 w3.org 或是 whatwg.org 裡面找到，資源相當豐富。
雖然說瀏覽器的實作有可能跟規範寫的不一樣（像是這篇），但 spec 已經是最完整而且最有權威性的一個地方了，因此來這邊找準沒錯。
如果搜尋 CORS 的 spec，可能會找到 RFC6454 - The Web Origin Concept 以及 W3C 的 Cross-Origin Resource Sharing，但這兩份都叫這一份叫做 Fetch 的文件給取代了。
當初我疑惑了一陣子想說是不是自己看錯，fetch 跟 CORS 有什麼關係？後來才知道原來這邊的 fetch 跟 Web API 那個 fetch 其實不同，這份規格是定義了所有跟「抓取資料（fetch）」有關的東西，就如同它的大綱所寫的：
The Fetch standard defines requests, responses, and the process that binds them: fetching.
這一篇就讓我們一起來看一下 CORS 相關的規範，證明我前面幾篇沒有在唬爛你，講得都是有所根據的。因為規格還滿長的，所以底下就是我挑幾個我認為的重點講而已，想要理解所有的規格內容，還是需要自己去看才行。
在上一篇裡面我們提到了常見的 CORS 錯誤解法，以及大多數狀況下應該要選擇的解法：「請後端加上 response header」。
但其實「跨來源請求」這個東西又可以再細分成兩種，簡單請求跟非簡單請求，簡單請求的話可以透過上一篇的解法來解，但非簡單請求的話就比較複雜一些了。
除此之外，跨來源請求預設是不會把 cookie 帶上去的，需要在使用 xhr 或是 fetch 的時候多加一個設定，而後端也需要加一個額外的 header 才行。
與 CORS 相關的 header 其實不少，有些你可能聽都沒聽過。原本這篇我想要把這些東西一一列出來講解，但仔細想了一下覺得這樣有點太無趣，而且大家應該看過就忘記了。
那怎樣的方法會比較好呢？大家都喜歡聽故事，因此這篇讓我們從故事的角度下手，為大家講述一段愛與 CORS 的故事。
主角的名字大家都知道了，對，就是毫無新意的小明。
在上一篇 CORS 完全手冊（一）：為什麼會發生 CORS 錯誤？裡面，我們理解了為什麼瀏覽器要有 same-origin policy，以及跨來源請求擋的其實是 response 而不是 request。在釐清了一些錯誤的觀念以及對 CORS 有基本的認知以後，就可以來講講怎麼樣解決 CORS 的問題。
先跟大家預告一下，這篇會提到的解決問題的方法並不完整。事實上，跨來源請求分成兩種，簡單請求跟非簡單請求，「跨來源請求擋的其實是 response 而不是 request」基本上只適用於簡單請求，而這一篇只會針對「簡單請求」，至於到底怎麼分簡單還是非簡單，以及非簡單的要如何處理，這些都會在下一篇提到。
想要解決基本的 CORS 錯誤，其實有滿多種方法，先來介紹幾個「治標不治本」的：
以下就會先針對這三個方法再進一步講解，講完以後我們會來講最後一個也是最正確的做法：「請後端加上 CORS header」。
三年前的時候寫了一篇文章：輕鬆理解 AJAX 與跨來源請求，提到了串接 API、AJAX、same-origin policy、JSONP 以及 CORS，當時把自己想講的都放進去了，但現在回頭看，好像有很多滿重要的部分沒有提到。
三年後，再次挑戰這個主題，並且試著表達地更完整。
會想寫這個系列是因為在程式相關的討論區上，CORS 是發問頻率很高的主題，無論是前端或是後端都有可能來問相關的問題。
所以我就想說：「好，那我來寫一個系列好了，我要試著把這個主題寫到每個碰到 CORS 問題的人都會來看這個系列，而且看完以後就知道該怎麼解決問題」，這算是我對這篇文章的目標，如果文章的品質沒辦法達成這個目標，我會持續改進。
這系列一共有六篇文章，分別是：
會從 same-origin policy 開始講起，接著講到為什麼跨來源存取資源會有錯誤，再來會講如何錯誤地以及正確地解決 CORS 相關的問題，而第三篇會詳細講解跨來源請求的詳細流程，像是 preflight request 之類的東西。
基礎的部分看前三篇就夠了，接下來會比較深一點。第四篇會帶你一起看 spec，證明前面幾篇不是我在虎爛的，而第五篇則是帶大家看看 CORB（Cross-Origin Read Blocking）、COEP（Cross-Origin Embedder Policy）或是 COOP（Cross-Origin-Opener-Policy）之類的跨來源相關規定，以及相關的安全性問題，最後一篇則是一些比較零散的主題以及心得感想。
說身為一個前端工程師，理所當然會知道很多與前端相關的知識，像是 HTML 或是 JS 相關的東西，但那些知識通常都與「使用」有關。例如說我知道寫 HTML 的時候要 semantic，要使用正確的標籤；我知道 JS 應該要怎麼用。可是呢，有些知識雖然也跟網頁有關，卻不是前端工程師平常會接觸到的。
我所謂的「有些知識」，指的其實是「資訊安全相關的知識」。有些在資訊安全裡面常見的觀念，雖然跟網頁有關，卻是我們不太熟悉的東西，而我認為理解這些其實是很重要的。因為你必須懂得怎麼攻擊才能防禦，要先知道攻擊手法跟原理，才知道該怎麼防範這些攻擊。
部落格需要顯示發佈時間，餐廳網站要顯示訂位時間，拍賣網站則是要顯示訂單的各種時間，無論你做什麼，都會碰到「顯示時間」這個很常見的需求。
這問題看似簡單，不就是顯示個時間嗎？但如果牽扯上「時區」的話，問題就會變得再更複雜一些。以時區來說，通常會有這幾個需求：
而這還只是顯示的部分而已，還有另外一個部分是與後端的溝通，這個我們可以待會再提，但總之呢，要正確處理時間跟時區並不是一件簡單的事。
在最近這一兩份工作剛好都有碰過相關的問題，因此對這一塊有點小小心得，就寫了這一篇來跟大家分享一下。
附註：目前這個 blog 對於 JSX 的語法支援有問題，所以看程式碼的時候可能沒那麼容易閱讀，我會盡快再找時間修復。
這個標題致敬了有寫 JavaScript 的人就算沒看過也一定聽過的一系列書籍：Kyle Simpson 寫的 You Don’t Know JS（中譯版翻成《你所不知道的 JS》），裡面講了許多很多人不知道的，有關於 JS 的東西。
而 I don’t know React 是我對我自己的一系列紀錄，記錄了一些我所不知道的 React，而這些文章都是由我使用 React 的經驗總結而來。這一些我曾經碰到過的錯誤，有可能很基本很常見（官方文件上面就有寫的那種，只是我沒看清楚所以不知道），也有可能比較少見（我可能在工作上寫三四年才碰到）。
換句話說，寫這系列的精神跟 YDKJS 不一樣，前者是想告訴你一些 JS 當中比較少人知道的東西，是一種「我來教你寫 JS」的感覺，而我寫這系列之所以叫做「I don’t konw」，是因為想用一系列的文章記錄自己寫 React 曾經有過的誤解或者是沒有注意到的地方，以及正確答案到底是什麼。
我也不知道這系列文會有幾篇，大概就是我每犯下一個就會來 po 個文。這系列有一個我覺得滿大的不同點，就是我會在文章開頭盡可能提供當時犯錯的場景重現，讓大家能有機會在看答案之前自己 debug，看看是否能找出錯誤在哪。我覺得這其實是最精華的部分，這不是什麼制式的面試考題，也不是從網路上隨便找來的 React 測驗，而是我在工作上碰到過的真實的狀況。
因為想要讓大家盡可能融入情境，也去思考我曾經碰過的問題，所以會有不少篇幅在於「定義以及重現問題」，如果你對自己尋找答案沒有興趣，也可以直接跳過這個部分去看解答。但我個人建議是自己先嘗試 debug，去發現問題在哪，才來看文章內的解答，才能完整地吸收文章想表達的東西。
總之呢，讓我們先來看看這一篇要講的案例吧！
最近在臉書上的前端社群看到了一篇文章：理解 React useEffect 02，內容是有關於 useEffect 的使用方式，後來在留言串也有了一些討論。
其實當初第一眼看到這篇文章的用法，我也是覺得有些奇怪，不過我其實多少能夠理解為什麼是這樣寫，只是還是覺得怪怪的。原本想留言，但是後來覺得「搞不好奇怪的是我」，就想說再思考一下。仔細思考過後，奇怪的還真的是我。
因此這篇來講一下我的想法，有錯的話歡迎在文章底下留言指正，或是在前端社群跟我討論也可以。在繼續閱讀之前，建議先看過上面那篇原文以及原文底下的討論，才會比較進入狀況。
Update your browser to view this website correctly. Update my browser now