這陣子在 Front-End Developers Taiwan 臉書社團上有一系列關於 Tailwind CSS 的討論，起因是另一篇已經刪除的貼文，那篇貼文我有看過，因為怕原文內容跟記憶內容有落差，因此這邊就不講我記憶中的原文大概是在寫什麼了，畢竟這也不是這篇所關注的重點。
總之呢，那篇貼文引起了臉書上前端社團的熱烈討論，在短短兩三天內迅速多出許多討論相關技術的文章。
而有許多人在討論的議題，其實比起 Tailwind CSS 這個工具，更多的是在討論 Atomic CSS 這個概念本身。
這陣子在 Front-End Developers Taiwan 臉書社團上有一系列關於 Tailwind CSS 的討論，起因是另一篇已經刪除的貼文，那篇貼文我有看過，因為怕原文內容跟記憶內容有落差，因此這邊就不講我記憶中的原文大概是在寫什麼了，畢竟這也不是這篇所關注的重點。
總之呢，那篇貼文引起了臉書上前端社團的熱烈討論，在短短兩三天內迅速多出許多討論相關技術的文章。
而有許多人在討論的議題，其實比起 Tailwind CSS 這個工具，更多的是在討論 Atomic CSS 這個概念本身。
如果你的網站想要搶先體驗瀏覽器還沒有正式上線的新功能，該怎麼做呢？
通常這些功能已經做好了，只是沒有開放而已，因此瀏覽器都會提供一些可以開關的 flag，只要把開關打開，就能夠搶先體驗到新功能，但我們通常不太可能叫使用者自己把開關打開。
因此，Chrome 提供了一個機制叫做 origin trials，你可以在網站上註冊，取得一組 token，接著只要設置好以後，如果使用者是用 Chrome 造訪你的網站，那就會開啟新功能，讓你的網站可以使用。
這篇就來簡單介紹一下這個機制該如何使用。
Same site 跟 same origin 雖然看起來有點像，但其實差別不小，而這個差別也會影響到瀏覽器如何看待這兩個網站的關係還有給予的權限。
這篇文章將會談到：
事不宜遲，就讓我們開始吧！
（開始之前先回答一個疑問。是的，標題的靈感來自於忍者哈特利）
2022-01-20：修改「細究 same site」段落，補充 scheme 相關歷史，感謝 @littlegoodjack
之前在公司內接到了一個需求，需要產生出一份 PDF 格式的報告。想要產一份 PDF 有很多種做法，例如說可以先用 Word 做，做完之後再轉成 PDF。但我聽到這需求時，最先出現的想法就是寫成網頁，然後再利用列印功能轉成 PDF。
我在前公司的時候看過一個用 JS 來產生 PDF 的專案，是用 PDFKit 來做，自由度極高，但我覺得滿難維護的。原因是用這一套的話，就有點像是把 PDF 畫出來，你要指定 (x,y) 座標去畫東西，可能改一個小地方，就要改很多行程式碼。
那時候我想說怎麼不直接用最簡單的 HTML + CSS 就好，切好版之後再轉成 PDF，如果不想手動轉，也可以透過 headless chrome 去轉，因為是網頁的關係所以應該滿好維護的。而且排版的話因為是用 HTML 跟 CSS，應該會比用畫的簡單許多才對。
直到我後來接觸到網頁轉 PDF，才發現事情不像我想的這麼簡單。
只要是開發 JavaScript 相關的專案，我的起手式通常都是 ESLint + Prettier，如果你沒有聽過這兩套的話我稍微講一下，Prettier 是幫你格式化程式碼用的，用了之後不必再跟其他人爭論到底要不要加分號，if 區塊的 { 要不要換行，一行最多到底能幾個字。只要用 Prettier，就是讓它幫你全權決定（雖然也有設定檔可以調整就是了）。
這其實對團隊滿有幫助的，因為程式碼格式可以統一，要空幾格也可以統一，在基本的 coding style 上面會長差不多。而 ESLint 雖然也有些跟格式相關的部分，但更多的是寫程式時候的一些 best practice，例如說使用變數前要先宣告、不會更改的變數用 const 之類的，這已經脫離了格式的範圍。
所以 ESLint 搭配 Prettier，就可以讓整個 codebase 的品質有最低限度的保障，至少不會出現排版很慘烈的狀況。而使用 ESLint 時最多人搭配的規則應該就是 Airbnb JavaScript Style Guide，裡面有每一條規則的詳細解釋。
之前在寫 code 時我突然想到一個地方好像很適合用 ESLint，就嘗試了看看，發現要做一個「堪用」的 plugin 比想像中簡單一些，就以這篇文章記錄一下過程跟心得。
這篇技術含量比較少一點，來跟大家分享一下寫這系列文的過程以及寫完之後的一些感想。
如果你還沒看這系列文的話，傳送門如下：
在前面幾篇裡面，我們知道 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 的故事。
主角的名字大家都知道了，對，就是毫無新意的小明。