#CORS

前言

這篇技術含量比較少一點,來跟大家分享一下寫這系列文的過程以及寫完之後的一些感想。

如果你還沒看這系列文的話,傳送門如下:

閱讀更多

前言

在前面幾篇裡面,我們知道 CORS protocol 基本上就是為了安全性所產生的協定,而除了 CORS 以外,其實還有一系列跟跨來源有關的東西,例如說:

  1. CORB(Cross-Origin Read Blocking)
  2. CORP(Cross-Origin Resource Policy)
  3. COEP(Cross-Origin-Embedder-Policy)
  4. COOP(Cross-Origin-Opener-Policy)

是不是光看到這一系列很類似的名詞就已經頭昏眼花了?對,我也是。在整理這些資料的過程中,發現跨來源相關的安全性問題比我想像中還來得複雜,不過花點時間整理之後發現還是有脈絡可循,因此這篇會以我覺得應該比較好理解的脈絡,去講解為什麼會有這些東西出現。

除了上面這些 COXX 的各種東西,還有其他我想提的跨來源相關安全性問題,也會在這篇一併提到。

在繼續下去之前先提醒一下大家,這篇在講的是「跨來源的安全性問題」,而不單單只是「CORS 的安全性問題」。CORS protocol 所保護的東西跟內容在之前都介紹過了,這篇要談的其實已經有點偏離大標題「CORS」完全手冊,因為這跟 CORS 協定關係不大,而是把層次再往上拉高,談談「跨來源」這件事情。

所以在看底下的東西的時候,不要把它跟 CORS 搞混了。除了待會要講的第一個東西,其他的跟 CORS 關係都不大。

閱讀更多

前言

在上一篇裡面我們提到了常見的 CORS 錯誤解法,以及大多數狀況下應該要選擇的解法:「請後端加上 response header」。

但其實「跨來源請求」這個東西又可以再細分成兩種,簡單請求跟非簡單請求,簡單請求的話可以透過上一篇的解法來解,但非簡單請求的話就比較複雜一些了。

除此之外,跨來源請求預設是不會把 cookie 帶上去的,需要在使用 xhr 或是 fetch 的時候多加一個設定,而後端也需要加一個額外的 header 才行。

與 CORS 相關的 header 其實不少,有些你可能聽都沒聽過。原本這篇我想要把這些東西一一列出來講解,但仔細想了一下覺得這樣有點太無趣,而且大家應該看過就忘記了。

那怎樣的方法會比較好呢?大家都喜歡聽故事,因此這篇讓我們從故事的角度下手,為大家講述一段愛與 CORS 的故事。

主角的名字大家都知道了,對,就是毫無新意的小明。

閱讀更多

前言

在上一篇 CORS 完全手冊(一):為什麼會發生 CORS 錯誤?裡面,我們理解了為什麼瀏覽器要有 same-origin policy,以及跨來源請求擋的其實是 response 而不是 request。在釐清了一些錯誤的觀念以及對 CORS 有基本的認知以後,就可以來講講怎麼樣解決 CORS 的問題。

先跟大家預告一下,這篇會提到的解決問題的方法並不完整。事實上,跨來源請求分成兩種,簡單請求跟非簡單請求,「跨來源請求擋的其實是 response 而不是 request」基本上只適用於簡單請求,而這一篇只會針對「簡單請求」,至於到底怎麼分簡單還是非簡單,以及非簡單的要如何處理,這些都會在下一篇提到。

想要解決基本的 CORS 錯誤,其實有滿多種方法,先來介紹幾個「治標不治本」的:

  1. 關掉瀏覽器的安全性設置
  2. 把 fetch mode 設成 no-cors
  3. 不要用 AJAX 拿資料

以下就會先針對這三個方法再進一步講解,講完以後我們會來講最後一個也是最正確的做法:「請後端加上 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)之類的跨來源相關規定,以及相關的安全性問題,最後一篇則是一些比較零散的主題以及心得感想。

閱讀更多

前言

當你獲得了一個知識之後,要怎樣才能知道那是正確的還是錯誤的?在程式的領域中這其實是一個相對簡單的問題,只要去確認規範是怎麼寫的就可以了(如果有規範的話)。

舉例來說,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 相關的規範,證明我前面幾篇沒有在唬爛你,講得都是有所根據的。因為規格還滿長的,所以底下就是我挑幾個我認為的重點講而已,想要理解所有的規格內容,還是需要自己去看才行。

閱讀更多