在此記錄一下跟同事之間切磋、交流後的一些筆記。

state

state 在 RFC 6749 #10.12 有提到相關用途，主要是為了防範 CSRF。看了滿多網路上的資源都沒有提到相關的攻擊細節，研究了很久，終於有點心得。

情境

假設有個網站（grass-fed.engineer），可以讓使用者在上面做筆記，使用者可以在登入後，選擇將筆記存入自己的 GitHub (github.com) 中。

1. 使用者會先登入 grass-fed.engineer，做完筆記，然後按下按鈕將筆記存入 GitHub 中。

2. 因為會需要存取 GitHub 的資源，按下「存入 GitHub」按鈕後，使用者會被導向 GitHub OAuth 授權存取。這時瀏覽器網址會是

   1	https://github.com/login/oauth/authorize?redirect_uri=https://grass-fed.engineer/oauth/callback

3. 使用者在 GitHub 完成授權後，會被導向

   1	https://grass-fed.engineer/oauth/callback?code=XMPcVwx8vngm7NhJIAQdQPAwKH2m2YUZ

4. Client 收到 request，會拿出 code，搭配 client_secret 到 GitHub 交換 access_token。

潛在問題

一切都看似美好，但是其實任何人都可以透過讓使用者呼叫 https://grass-fed.engineer/oauth/callback?code=<壞人的 code> 來欺騙 client 執行第 4 步。

這樣就有可能使用者綁定的 GitHub 帳號會變成壞人的帳號。

聽起來好像是壞人把自己帳號送了出去，沒什麼好處，但是從此以後，壞人就會拿到所有使用者想存在自己帳號的筆記。

輸出筆記事小，但是如果是 PayPal 存入授權，想來就是會出大事的。

實務上的操作可以是透過網頁的 img tag 嵌入壞人的 URL，讓瀏覽器在下載圖片時變成收到 redirect 請求，進而跳到 grass-fed.engineer 進行帳號授權綁定壞人的 GitHub 帳號。

解方

state 是由 client 產生，令人難以捉摸的一串字，通常會被存放在 cookies 或是 local storage 裡，並且會跟隨第 1 步一起送給 Authorization Server。

1

https://github.com/login/oauth/authorize?state=9YVefLNc&redirect_uri=https://grass-fed.engineer/oauth/callback

Authorization Server 會在第 3 步重新導向時，在 URI 加入相同的 state。

1

https://grass-fed.engineer/oauth/callback?state=9YVefLNc&code=XMPcVwx8vngm7NhJIAQdQPAwKH2m2YUZ

Client 在收到 request 後，會驗證 URL 中的 state 是否跟 local 的 state 相同，如果是，就代表這個 request 當初是自己發出去的，可以開始兌換 access_token；如果不相同，就代表有可能被偽冒了，必須終止兌換流程。

小結

state 可以用來確保 request 確實是在同一個 client 發送的，而不是他人任意給的假冒 request。

PKCE

PKCE，全名是 Proof Key for Code Exchange，是 OAuth 2.0 的一種擴充協議。主要是為了解決部分 client 無法安全保護 client_secret 以及 authorization code 時的一種安全驗證機制。

情境

最常見的場景是原生手機 app，使用者在瀏覽器上完成 Authorization Server 授權後，Authorization Server 會重新導向至指定 URL。

這種 URL 的 protocol 通常不是 http:// 或 https://，而是如 engineer:// 這類的 deep link，這樣一來才能夠將使用者導回 app 中。

這類的 deep link 仰賴手機作業系統處理，使用者的手機極有可能暗藏惡意軟體，會從中攔截 code，然後利用 code 換取不當授權。

解方

原生手機 app 產生 code_verifier，並利用特定方式生成 code_challenge，詳細內容可以參考 RFC 7636 #4.1。

在 URL 中加入特定參數 code_challenge，並利用瀏覽器開啟連結進行授權

1

https://github.com/login/oauth/authorize?code_challenge=DU5hBtgoNO7ejhinrnvxNOFvc5JQyA6Ki7MmFsFIdJzViY&redirect_uri=engineer://oauth/callback

Autorization Server 完成授權後，會將 code_challenge 跟 code 存下，之後會導向至

1

engineer://oauth/callback?code=9O5avOd4vlOTY6Ye96JSyRxSIDKGQIzF

原生手機 app 開啟，並利用 code 以及 code_verifier 交換 access_token。如果 Authorization Server 上的 code_challenge 跟傳送上來的 code_verifier 相符，則配發 access_token；反之，不配發 access_token。

這樣一來即使 code 被攔截，也很難真的換到 access_token。

小結

在沒有辦法安全保存 client_secret 的環境中，可以使用 PCKE 產生一次性的驗證金鑰，確保 code 不會任意被攔截並換取不屬於自己的 access_token。

該用什麼？

state 跟 PKCE 看似相似，但效用非常不同：

• state：防止壞人利用自己的 code 讓好人綁錯帳號
• PKCE：防止 code 被壞人攔截並挪作他用

最佳作法是兩者皆要實作才可以換取較高的安全性。

參考資料

• Authorization Code Flow with Proof Key for Code Exchange (PKCE)
• Does PKCE replace state in the Authorization Code OAuth flow?

最近工作上遇到一個難題，我們的背景處理系統 Sidekiq，在 AWS Auto Scaling 自動關閉機器時，有部分的任務會憑空消失。

記錄一下追蹤問題的過程，並奉上目前的解法，希望對未來遇到此問題的人能有些幫助。

此文寫於 2021 年 10 月 24 日，解法可能因時序推移而不再適用，請自行斟酌。

系統設定

我們的服務是透過 AWS Elastic Beanstalk 部屬的 Ruby on Rails 應用程式，除了處理 HTTP 流量的 Puma 之外，還配有一支背景處理服務 Sidekiq，而使用的作業系統是 Amazon Linux 2。

Elastic Beanstalk 使用的是 Load Balancing 的模式，所以系統會自動根據負載開啟或是關閉機器。

而 Puma 及 Sidekiq 在機器上都是使用 systemd 執行的服務。

問題描述

我們有一個每隔 10 秒會執行一次的任務，每次執行的時間根據系統狀況有所不同，5 秒至 80 秒都有可能。

為了避免塞爆 Sidekiq 的任務佇列（job queue，通常是 Redis），所以我們希望的行為模式是：執行完畢後 10 秒再執行一次，用程式碼來看會是一個這樣的任務：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

class CleaningService
  include Sidekiq::Worker
  
  def perform
    do_some_cleaning

    # 完成後 10 秒再做一次
    CleaningService.perform_in(10.seconds)
  end

  private

  def do_some_cleaning
    # 有可能執行超過 30 秒
  end
end

Sidekiq 有 graceful shutdown 的設計：

• 收到「停止服務」訊號時，會暫停接受新任務，並且嘗試把正在執行的任務執行完
• 過了一段時間，會強制把未完成的任務中止，並且把這些任務重新塞回任務佇列

所以理論上來說，Sidekiq 的任務至少會被執行一次¹。

以上面的 CleaningService 來說，如果 do_some_cleaning 執行到一半被中止，應該會被放回任務佇列，待 Sidekiq 重新啟動時再從頭開始執行。

但實際上這個任務常常過了幾個小時就自己消失了！

追蹤問題來源

我先自己推測幾個可能的原因會造成這個現象：

1. CleaningService 有 bug，造成 Sidekiq 崩潰
2. Sidekiq 的 bug 導致任務沒有被重新被放回任務佇列
3. Auto Scaling 關閉機器時，沒有讓 Sidekiq 執行 graceful shutdown

其中 1. 在經過簡單的測試以及檢視紀錄檔（log）後，可以排除。

而 2. 實際上可以透過升級成 Sidekiq Enterprise 並使用 Redis 的 SuperFetch 來保證任務執行完後才把任務從佇列中刪除²，但我猜測作者應該沒這麼壞心，故意留一個 bug 想讓大家升級到 Enterpise。此外，在手動關閉 Sidekiq 時，的確可以看到 Sidekiq 把任務重新塞回佇列。所以這個也先暫時排除。

雖然覺得很不可能，但是還是得研究 3. 會不會發生。

真的是 Auto Scaling 在搞鬼嗎？

為了瞭解 Auto Scaling 機器上的狀況，我先在機器上安插了一支 systemd 服務，會在關機前將紀錄檔打包，並且上傳到 S3。

紀錄檔裡的 Sidekiq 紀錄很不幸的，只有以下內容：

1
2

...
INFO: Shutting down

原本預期應該有的「讓執行中的任務有機會完成」以及「強制把未完成的任務中止，並且把這些任務重新塞回任務佇列」都沒有被記錄到。

但可以知道的是，系統有嘗試執行正常關閉程序，但是後面發生了什麼事，不得而知。

S3 沒有紀錄，那硬碟上有嗎？

為了更進一步瞭解問題，我開始懷疑傳到 S3 上的資料有少，但因為機器在關閉之後，附掛在上面的硬碟也會一起被刪除，所以沒辦法直接看裡面的內容。

這裡可以透過 AWS 的 API，將機器的硬碟設定為「不隨機器關閉而刪除」³，這樣一來，就可以在機器關閉之後，另外開一台新的機器，並掛載舊的硬碟⁴，查看關機後舊硬碟上的資料。

在這之前，我還另外把寫入紀錄檔用的服務 rsyslog 設定為採用永久性儲存，避免在關機過程中，因為 rsyslog 因為過早被關閉，而遺失後續尚未關閉的服務產生的紀錄檔⁵。

硬碟上真的有！

在掛上舊硬碟之後，打開 Sidekiq 的紀錄檔，發現最後幾行寫著：

1
2
3
4
5
6
7
8
9
10
11
12

INFO: Shutting down
INFO: Terminating quiet workers
INFO: Scheduler exiting...
INFO: Pausing to allow workers to finish...
ERROR: heartbeat: Error connecting to Redis on redis.cache.amazonaws.com:6379 (SocketError)
WARN: Terminating 1 busy worker threads
WARN: Work still in progress [#<struct Sidekiq::BasicFetch::UnitOfWork queue="queue:default", job="{\"retry\":true,\"queue\":\"default\",\"class\":\"CleaningService\",\"args\":[],\"jid\":\"707373d5bfbefe4aa077a2dc\",\"created_at\":1634188450.4219317,\"enqueued_at\":1634188450.422139}">]
WARN: Failed to requeue 1 jobs: Error connecting to Redis on redis.cache.amazonaws.com:6379 (SocketError)
INFO: fail
INFO: Bye!
ERROR: heartbeat: Error connecting to Redis on redis.cache.amazonaws.com:6379 (SocketError)
WARN: Unable to flush stats: Error connecting to Redis on redis.cache.amazonaws.com:6379 (SocketError)

可以看到系統有嘗試讓 Sidekiq 進行 graceful shutdown，不過 Sidekiq 在當時已經沒有辦法跟 Redis 連線了。主要是因為網路層的服務比 Sidekiq 更早被關閉，所以產生此現象。

怎麼解決？

要解決這個問題最直接的方式就是修改 Sidekiq 的 systemd 服務描述檔，讓它會在網路層的服務關閉前先關閉。

但因為我們目前使用的是 AWS 的 Elastic Beanstalk，描述檔是由它自動產生的，如果要修改，可能會需要在每次有系統升級時，都確定沒有影響到其餘的功能，維護的成本偏高，所以暫時不考慮。

EC2 Auto Scaling Lifecycle Hooks

除了上述方法外，其實 AWS 的 Auto Scaling 有針對這種使用情境，設計專門的機器狀態，讓開發者在機器關閉前，進行一些必要的步驟，以確保機器可以安全地被關閉⁶。

在機器關閉前，Auto Scaling Group 會先讓機器進入 Terminating:Wait 的狀態，此時有至多 7,200 秒的時間執行必要的動作，動作完成後，由開發者觸發 API 讓機器進入 Terminating:Proceed 狀態，機器就會正式關閉。

完整解法架構

最後採用的完整的流程如下，Auto Scaling Group 根據給定規則，決定該關閉機器 (scale in)，Auto Scaling Group 將欲關閉的機器設定為 Terminating:Wait 狀態。

這邊需要先在 Auto Scaling Group 中建立 Lifecycle hooks，加入 Instance Terminate 的 hook，詳細的操作方式可見官方文件。

接著執行 graceful shutdown 流程。

這裡可以透過 AWS Systems Manager 搭配 AWS EventBridge 來實作。

Systems Manager 是用來管理機器的服務，其中包含：在機器上執行一段腳本、呼叫 AWS API；而 EventBridge 則是可以監聽在 AWS 服務中被觸發的事件，然後進行相關操作。

利用過 EventBridge 監聽 Terminating:Wait 事件，收到事件後，觸發在 Systems Manager 裡預先撰寫好自動化文件，即可進行 graceful shutdown 以及呼叫 API，最後完成關機步驟。

在 Systems Manager 自動化文件的最後一個步驟，觸發 AWS API 讓機器進入 Terminating:Proceed 狀態：

Auto Scaling Group 在收到請求後，正式將機器關閉：

詳細的 Systems Manager 自動化文件可以參考這個 Gist。

套用這個解法後，可以從紀錄檔中看到 Sidekiq 正確的被停止，並且把未完成的任務放回任務佇列，確確實實地解決這個問題。

後記

Debug 最美好的就是一切苦盡甘來的感覺，但如果可以，還是不要苦最好。感謝你讀到這裡，祝福你所有的問題，都可以從 Stack Overflow 複製貼上就解決 😌

Apple 在第一台 Mac 上市時，就在電腦裡提供眾多字體選項，當時在業界是創舉。甚至到後來的 iPhone 中內建 Emoji，也直接地幫助使用者可以產生更豐富的內容。

在 2019 年，Apple 也為軟體開發者提供了一系列扁平化的圖示，可以讓 app 開發者使用風格一致的圖示設計使用者介面。

這套圖示除了提供給 app 開發者使用的程式介面之外，也提供了給設計師使用的概覽程式：SF Symbols。

這些圖示可以匯入 Keynote 使用，為投影片注入更多視覺化元素。

除了設計風格一致之外，因為匯入的內容是實質上是文字，所以可以無限制的縮放而不失真，此外，所有可以套用在文字上的效果也都可以套用在匯入的內容上。

下載、安裝

相當簡單，只需要到 SF Symbols 網站下載 SF Symbols（本文撰寫時為 SF Symbols 3 beta），下載完成後，利用下載回來的安裝檔進行安裝即可。

使用

開啟瀏覽程式 SF Symbols Beta

• 中間圖示部分為預覽區
• 左側欄可以根據類別瀏覽
• 右上角可以進行搜尋（只能用英文）

在選定圖示後，對圖示按下右鍵 > 選擇「Copy Symbol」

到 Keynote 中按下右鍵 > 貼上，就可以看見圖示以文字框的形式出現。

接著就可以根據需求修改大小、效果等等。

下圖是套用了漸層以及一些動畫，簡單模擬出的「燒腦」效果：

後記

最近剛好有需要在公司分享一些內容給同事，偶然發現可以這樣使用 SF Symbols。這個小技巧節省了許多找素材的時間，同時也為投影片的質感加分不少。

可惜的是，網路上比較少資源在討論相關內容，所以決定自己撰寫一篇短文。

如果你也覺得實用，歡迎分享給你的朋友、同事，讓他們也能一起享受這些優質的設計資源。

初來乍到，前面的幾個專案中，花了不少時間帶著他熟悉整體程式碼的結構以及一些實作細節，所以基本上都是由他撰寫程式碼，而我負責審核。

這位同事的背景跟我很不一樣，我是一路大學、研究所都唸的是資訊工程，而他是自學程式設計，正是這個差異，讓我們之間有了不少火花。

某次審核他的程式碼時，看到下面這段，腦袋中充滿了各式的疑惑。

1

if (condition == false) { ... }

「為什麼要寫 == false？」
「不是寫 !condition 就好了嗎？」
「他是不是不知道怎麼用 !？」

我嘗試在提出改成用 ! 的建議，這個建議非但沒有被採納，反而得到了令相當訝異的回覆。

「用 == false 比較好讀懂，用 ! 很容易漏看。」

這是我進入職場之後，少數幾個具有啟發性的時刻

只有自己寫程式的時候，完全不會在意這樣的事情，自己寫、自己看，非常難看到自己的盲點。

簡單易懂的程式碼容易維護，但看起來就是不夠「精明」。許多程式設計師喜歡比拼「誰寫得短」、「誰用了比較炫的語法」等等，我曾經也是這樣的人，但這些習慣都極有可能造成程式未來不易讀懂，也就變得更難維護了。

在被點醒之後，我開始鑽研如何寫出「精簡」的程式碼，發現其實真的相當不容易。最洗練的程式碼的產生過程往往需要經過抽象化，再反向的把抽象化的結果用最簡單的方式呈現。

學習如何實踐的過程，有發現一些還不錯的資源，其中一個我覺得相當受用的訪談，就在討論如何用最直觀的方式表達你的邏輯。

這次的學習經驗很寶貴，完美地呈現了「教學相長」，我一直以為我是在教他，但其實真正學到東西的是我。

程式設計是一條漫長且孤獨的路，每位程式設計師都是走在自己獨一無二的路上，每次的相遇，都是寶貴的學習機會，值得好好把握，共勉之。

也許是耳濡目染，對於宮廟系統幾乎是沒什麼抵抗力，到外縣市玩時會想要去當地著名的廟宇參拜，甚至就連去日本玩一定都是先查神社以及搜集朱印。

某次在 Costco 進行例行採買時剛好瞄到這本書，翻了一下覺得很喜歡，就帶回家了，但這本書比我想像中的更值得一讀。

書中整理了台灣民間信仰中較常見的神靈，佐以一些較為獨特的神靈（如器物、動物崇拜），搭配作者對於神靈形象插畫，整體內容讀來輕鬆有趣。

疫情流行時期，農曆新年走訪宮廟絕對不是明智之舉，但是透過這本書以及網路搜尋資料，也能夠進行一段段虛擬進香，也為未來疫情結束後的旅遊行程多埋下一些種子。

民俗信仰因民生需求而生，在以前靠天吃飯的年代蓬勃發展，現代生活，人們對於信仰的需求已經大不相同，有些傳統儀式未來可能也就只能在書中看到了。當然，也會有更多與時俱進的信仰及服務應運而生，不過神靈的故事將會永久流傳。

對於民俗信仰有足夠瞭解的讀者，這本絕對是值得收藏的優秀圖文書；而對於民俗信仰比較沒有涉獵的讀者，這本書也可以帶給你很多有趣的小故事，讓你更暸解祂們。

《寶島搜神》

作者：角斯
出版社：聯經出版公司
出版日期：2020 年 1 月 22 日
語言：繁體中文
ISBN：9789570854541

我想多數人應該跟我一樣，選擇開中古車，理由不外乎就是「開老車，磕碰比較不心疼」。

所以 2019 年 12 月考到駕照後，就入手了一台跟駕訓班上課用的相同車款。

那是一台剛滿 18 歲的車，車上只有收音機，甚至還沒有倒車雷達。

結果技術太差，開了不到半個月，就在社區停車場擦撞了鄰居的車 — 好不容易累積的一絲信心直接破滅。

「是不是可以讓車子來教我怎麼駕駛？」

我自顧自地覺得這是一個可行的學習方式。

趁著春節假期做了一些功課，在半個月後，決定購入輔助駕駛功能比較齊全的車款，讓它來教我開車。

這真是一個正確的決定

舉幾個我感受比較強烈的例子：

停車

透過雷達可以比較暸解跟附近障礙物的距離。如果雷達警告靠太近了，可以比對後視鏡跟車外周遭肉眼可見的樣貌，思考如何調整，這樣下次就可以用比較適當的方式停好車。

抓車距

使用自動跟車，可以觀摩電腦如何與前車保持適當距離，以及加速減速時機的掌控。

另外自動變道也讓我在切換車道時更有餘裕去觀察如何與後車保持適當距離，減少對於其他駕駛者的影響。

控制方向盤

車道維持則示範了如何把車開在車道中央，在有點弧度的路面上如何控制左右空間，不壓縮到鄰車的行駛空間。

學習的成果是帶得走的！

經過這樣「被示範」大約三個月，在公路上行駛時的穩定性有很顯著的提升。

比較有趣的是，原本以為會因此而依賴輔助駕駛，要完全自己開時會不知所措，但反而偶爾回頭去開老車時，也明顯地感覺到可以靠自己把車開好。

應該還可以再進步

開了三個月之後，幸運抽到統哥駕駛學院初級駕駛課程，課程內容讓我對於輔助駕駛的體會又更深了一些，之後有時間再另外寫一篇聊聊。

哦，對了，那輛教我開車的車是這台

如果你也想體驗看看，歡迎到特斯拉官方網站預約試駕。

訂車時也歡迎使用我的推薦連結訂購 https://ts.la/cyhsum72569，這樣你可以得到 1,500 公里免費的超級充電額度。