Huli
# 前言 2021-05-25 補充：文中所提到的在 target phase 會依照加上 event listener 的順序觸發，在新版的 Chrome 似乎更改了這個行為，請參考：[Chrome 89 更新事件触发顺序，导致99%的文章都错了（包括MDN）](https://juejin.cn/post/6965682915141386254) （補充：感謝 othree 前輩的指點，指出這其實是在講 DOM 裡面事件傳遞的順序，因此把標題以及內文修正，原標題為：JavaScript 的事件傳遞機制：捕獲與冒泡） 今天為大家帶來的內容是 DOM 裡面的事件傳遞機制，而與這些事件相關的程式碼，相信大家應該不太陌生，就是`addEventListener`, `preventDefault`跟`stopPropagation`。 簡單來說，就是事件在 DOM 裡面傳遞的順序，以及你可以對這些事件做什麼。 為什麼會有「傳遞順序」這一詞呢？假設你有一個`ul`元素，底下有很多`li`，代表不同的 item。當你點擊任何一個`li`的時候，其實你也點擊了`ul`，因為`ul`把所有的`li`都包住了。 假如我在兩個元素上面都加了`eventListener`，哪一個會先執行？這時候呢，知道事件的執行順序就很重要。...
## 前言 前陣子我為了幫自己的學生們更熟悉 HTTP 以及 API 的串接，寫出了一個小遊戲：[Lidemy HTTP Challenge](https://lidemy-http-challenge.herokuapp.com/start)，需要根據每一關的說明取得正確的 token，一共有十五關，前十關基本，後五關進階。 經過了一些朋友的測試之後，慢慢調整、改善，最後讓學生測試發現反應都不錯，於是就在[前端社群](https://www.facebook.com/groups/f2e.tw/permalink/2153812321322788/)正式對外公開這個遊戲，讓大家也能一起參與。 如果你還沒玩過，那強烈建議你不要看這篇文章，因為這篇文章會破壞你遊玩的興致（大概就跟電影爆雷一樣）。建議可以先去玩一下，等全破了再回來看這篇文章，會得到一些不同的收穫。 接下來我會講一下這個遊戲誕生的歷程以及每個關卡的設計。 ## 前人種樹，後人乘涼 這種以遊戲當做外殼，內容卻是滿滿技術的手法大家應該並不陌生，至少我很不陌生。 最一開始有想要做成遊戲的這個想法，其實是因為一個學生傳給我這個：[devtest](https://pretapousser.fr/devtest/)，這是法國某一間公司的面試考題，如果你看到畫面一片白，那絕對不是網頁壞掉，不用擔心。 破完了上面這個遊戲之後，我才想起自己對這種模式其實很不陌生。小時候玩過[高手過招](https://www.csie.ntu.edu.tw/~b94102/game/game.htm)，也玩過類似 [Hack This Site! ](https://www.hackthissite.org/) 的遊戲。 或是以前有一陣子解謎遊戲正夯（跟程式無關的那種），我也曾經自己做了一個，那時候是用 PIXNET 文章鎖密碼的方式來做關卡，現在想想真是個非常方便的方法。 總之呢，雖然小時候都玩過，但長大之後卻慢慢忘記還有這種模式。這種模式的好處就在於它是遊戲。遊戲做得好，每個人都會愛上它。而且會比一般的你問我答或是簡答題有趣多了，所以遊戲是個很好的切入點。 想起遊戲的好處以後，我就決定要自己來做一個了，而主題就是之前我的學生們最不熟悉的串接 Web API！...
## 前言 CSS 寫一陣子之後，大家對於常見的屬性應該都很熟了，例如說最基本的 display、position、padding、margin、border、background 等等，在寫 CSS 的時候不需要特別查什麼東西，很順的就可以寫出來。 這些屬性之所以常見，是因為許多地方都用得到所以常見，而有些 CSS 屬性只能使用在某些特定地方，或者是只有某個特定的情境之下才會出現。我很常會忘記這些沒那麼常用到的屬性，但在某些時候這些屬性其實特別重要。 因此這篇想來介紹一些我覺得不太好記但是卻很好用的 CSS 屬性，也是順便幫自己留個筆記。 ## input 的外框跟「那一根」的顏色 比起 border，outline 是一個比較少出現的屬性，但這邊要特別提的是在 input 上的應用。瀏覽器預設的行為中，當你 focus 到 input 時外層會出現藍色的一圈：  那個藍色的就是 outline，可以透過 Chrome...
## 前言 只要是開發 JavaScript 相關的專案，我的起手式通常都是 ESLint + Prettier，如果你沒有聽過這兩套的話我稍微講一下，Prettier 是幫你格式化程式碼用的，用了之後不必再跟其他人爭論到底要不要加分號，if 區塊的 `{` 要不要換行，一行最多到底能幾個字。只要用 Prettier，就是讓它幫你全權決定（雖然也有設定檔可以調整就是了）。 這其實對團隊滿有幫助的，因為程式碼格式可以統一，要空幾格也可以統一，在基本的 coding style 上面會長差不多。而 ESLint 雖然也有些跟格式相關的部分，但更多的是寫程式時候的一些 best practice，例如說使用變數前要先宣告、不會更改的變數用 const 之類的，這已經脫離了格式的範圍。 所以 ESLint 搭配 Prettier，就可以讓整個 codebase 的品質有最低限度的保障，至少不會出現排版很慘烈的狀況。而使用 ESLint...
## 前言 在上一篇裡面我們提到了常見的 CORS 錯誤解法，以及大多數狀況下應該要選擇的解法：「請後端加上 response header」。 但其實「跨來源請求」這個東西又可以再細分成兩種，簡單請求跟非簡單請求，簡單請求的話可以透過上一篇的解法來解，但非簡單請求的話就比較複雜一些了。 除此之外，跨來源請求預設是不會把 cookie 帶上去的，需要在使用 xhr 或是 fetch 的時候多加一個設定，而後端也需要加一個額外的 header 才行。 與 CORS 相關的 header 其實不少，有些你可能聽都沒聽過。原本這篇我想要把這些東西一一列出來講解，但仔細想了一下覺得這樣有點太無趣，而且大家應該看過就忘記了。 那怎樣的方法會比較好呢？大家都喜歡聽故事，因此這篇讓我們從故事的角度下手，為大家講述一段愛與 CORS 的故事。 主角的名字大家都知道了，對，就是毫無新意的小明。 ## Day1：簡單的 CORS 小明任職於某科技公司，擔任菜鳥前端工程師。...
## 前言 知道 CTF 這東西很久了，但直到前陣子才真正去參加了線上辦的 CTF 比賽，不過因為會的東西有限，只能打 web 題，或是剛好有涉獵的 misc 題。雖然本來就覺得 CTF 很有趣，但實際去玩了以後收穫比我想像中的還多。 身為一個前端工程師，知道各種前端相關的知識十分合理，然後又因為看得文章夠多，所以除了一些新的特性以外，平時比較難有那種：「哇！居然可以這樣」的感覺。但在用心打 CTF 的兩個假日裡面，我獲得了數次這種感覺，而且是：「哇靠！！！！居然可以這樣嗎！！！」，明明就屬於前端的範疇，但我卻從來都不知道還可以這樣。 我認為前後端工程師去打 CTF 的 web 題，可以補足前後端相關的知識，而且這種知識是你平常在工作中或是生活中很難獲得的，但卻在資訊安全的領域很常見。想要防禦，就必須先知道怎麼攻擊。 因此這篇就稍微分享一下 CTF 是什麼，該如何參加，又該怎麼解題。 ## 什麼是 CTF 其實可以先參考這兩篇文章： 1. [跨出成為駭客的第一步，來打打看...
## 前言 在上一篇 [CORS 完全手冊（一）：為什麼會發生 CORS 錯誤？](https://github.com/aszx87410/blog/issues/68)裡面，我們理解了為什麼瀏覽器要有 same-origin policy，以及跨來源請求擋的其實是 response 而不是 request。在釐清了一些錯誤的觀念以及對 CORS 有基本的認知以後，就可以來講講怎麼樣解決 CORS 的問題。 先跟大家預告一下，這篇會提到的解決問題的方法並不完整。事實上，跨來源請求分成兩種，簡單請求跟非簡單請求，「跨來源請求擋的其實是 response 而不是 request」基本上只適用於簡單請求，而這一篇只會針對「簡單請求」，至於到底怎麼分簡單還是非簡單，以及非簡單的要如何處理，這些都會在下一篇提到。 想要解決基本的 CORS 錯誤，其實有滿多種方法，先來介紹幾個「治標不治本」的： 1. 關掉瀏覽器的安全性設置 2. 把 fetch mode 設成...
## 前言 當你獲得了一個知識之後，要怎樣才能知道那是正確的還是錯誤的？在程式的領域中這其實是一個相對簡單的問題，只要去確認規範是怎麼寫的就可以了（如果有規範的話）。 舉例來說，JavaScript 的各種語言特性在 ECMAScript Specification 裡面都找得到，為什麼 `[] === []` 會是 false，為什麼 `'b' + 'a' + + 'a' + 'a'` 會是 baNaNa，這些在規範裡面都有，都會詳細說明是用怎樣的規則在做轉換。 而 Web 相關的領域除了 JS 以外，HTML 或是其他相關的規範幾乎都可以在 [w3.org](https://www.w3.org)...
## 前言 在前面幾篇裡面，我們知道 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 協定關係不大，而是把層次再往上拉高，談談「跨來源」這件事情。...
## 前言 三年前的時候寫了一篇文章：[輕鬆理解 AJAX 與跨來源請求](https://blog.huli.tw/2017/08/27/ajax-and-cors/)，提到了串接 API、AJAX、same-origin policy、JSONP 以及 CORS，當時把自己想講的都放進去了，但現在回頭看，好像有很多滿重要的部分沒有提到。 三年後，再次挑戰這個主題，並且試著表達地更完整。 會想寫這個系列是因為在程式相關的討論區上，CORS 是發問頻率很高的主題，無論是前端或是後端都有可能來問相關的問題。 所以我就想說：「好，那我來寫一個系列好了，我要試著把這個主題寫到每個碰到 CORS 問題的人都會來看這個系列，而且看完以後就知道該怎麼解決問題」，這算是我對這篇文章的目標，如果文章的品質沒辦法達成這個目標，我會持續改進。 這系列一共有六篇文章，分別是： * CORS 完全手冊（一）：為什麼會發生 CORS 錯誤？ * CORS 完全手冊（二）：如何解決 CORS 問題？ * CORS 完全手冊（三）：CORS 詳解...