[學習心得] LINE Bot 開發者指南 詳解 - 2. 使用 Webhook URL 接收請求時的注意事項

June 3rd, 2021

前言:

各位好， 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines 的投影片，考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外，並且特定用這一系列文章加以解釋，希望可以讓更多開發者有更多的了解。 Development guidelines 文件內容很多，本份投影片也將以五篇文章的篇幅來加以解釋。本篇文章為第二篇文章，主要講解的會是關於設定 LINE Bot Webhook 相關注意事項。

文章索引:

完整投影片鏈結： https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese

希望各位可以持續關注：

  1. 關於LINE Bot
  2. 使用Webhook URL接收請求時的注意事項(本篇文章)
  3. 發送 API 請求時的注意事項
  4. LINE Login
  5. LINE Login (補充）
  6. 其他相關功能

本篇文章將專注在第一個段落，也就是 Page 3 ~ Page 8 的部分。

Webhook URL 接受請求時的注意事項

本篇注意事項中，其實在「開發LINE聊天機器人不可不知的十件事」。有許多著墨，這裡稍微帶到與解釋。以下個別根據不同頁面來解釋。

  • A 考量安全性的通訊環境
  • B 接受到請求的時候，回覆狀態代碼 200
  • C 防止來自於 LINE 以外未經授權的請求
  • D 對於大規模訊息處理的考量

A 考量安全性的通訊環境

這部分提醒大家需要提升 Webhook 伺服器的安全環境，這邊也提醒大家根據 2021/01 的新聞 ([Updated] TLS 1.0 and TLS 1.1 support by the webhook notification source will be discontinued at the end of January 2021)，如果要能正常地接受到 LINE 平台的 Webhook 必須要讓伺服器支援到 TLS 1.3 。

更多訊息歡迎參考以下文章：

B 接受到請求的時候，回覆狀態代碼 200

在 「開發LINE聊天機器人不可不知的十件事」的文章的(第三件事：盡快回覆LINE平台正確的HTTP狀態碼). 中，也有提到 LINE平台在傳送事件訊息到開發者Webhook伺服器之後，若是等待1秒鐘沒有得到任何HTTP狀態碼的回覆，就會發生逾時（Timeout）錯誤，LINE平台會關閉該次HTTP連線並認為該次傳送結果失敗；若是一直發生傳送失敗的狀況，LINE平台可能會將該Webhook伺服器封鎖或進行其他處置，造成開發者的應用服務無法正常運作。 請開發者們要注意到相關的事項。

更多訊息歡迎參考以下文章：

C 防止來自於 LINE 以外未經授權的請求

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第二件事：驗證訊息來源)也有提到，當開發者的Webhook伺服器收到以POST方式所傳送的LINE事件訊息時，必須要立即驗證該事件訊息是否真的來自LINE平台，以避免被偽造的訊息所欺騙造成資訊安全危機。標準的驗證方式是檢查所收到HTTP請求標頭（HTTP request header）中的數位簽章。如果該HTTP POST訊息是來自LINE平台，在HTTP請求標頭中一定會包括X-Line-Signature項目，該項目的內容值是即為數位簽章。

更多訊息歡迎參考以下文章：

D 對於大規模訊息處理的考量

這邊有分享一些給開發者的經驗分享，根據業務的發展狀況下，以下幾個時間將會有大量的訊息灌入開發者們的 LINE Bot ，希望開發者們可能要注意到。 （訊息集中的部分）

針對這些大量的訊息可能湧入下，建議開發者們必須要有相關的備案需求。避免因為訊息過多而造成開發者的伺服器不堪負荷。 建議如下：

  • 是否有水平擴張的機制來面對大量的需求。 (Auto-scaling)
  • 建議檢查每一次訊息來之後的回覆時間，儘量採取非同步方式。盡可能先回覆之後，在另外發訊息給使用者。如此一來可以避免卡住太多訊息。

此外，本頁投影片也告知幾個重要消息：

  • 請勿對 GW 伺服器進行壓力測試，如果開發流程需要做壓力測試請透過其他方式來進行。 參考 Development guidelines。

E-1 Webhook 的 ON/OFF

這邊提到的是切換 Webhook 開關跟「自動回覆訊息」還有「加入好友的歡迎訊息」的解釋。 這邊主要提醒開發者們，如果忘記將「自動回覆訊息」關閉的話，即便你開起來 Webhook 的開關，雖然可以收到，還是會透過「自動回覆訊息」來回覆。 相關的細節在下一頁會有更多解釋：

相關資料：

E-2 Webhook 的 ON/OFF 選項設定（跟「自動回覆訊息」還有「自動歡迎訊息」的互動）

  • 使用「Webhook]，使用自動回覆與加入好友歡迎訊息：

    • 訊息來了，同時會送到 Webhook 與自動回覆。
    • 但是因為自動回覆會先回覆，Webhook 不需要再回覆即可。

  • 使用「Webhook]，不使用自動回覆與加入好友歡迎訊息：

    • 建議開發者使用這個方式，完全透過 Webhook 來收取訊息與發送訊息。

  • 不使用「Webhook]，使用自動回覆與加入好友歡迎訊息：

    • 這樣 Webhook 將不會收到訊息，完全透過自動回覆來回覆。

  • 不使用「Webhook]，不使用自動回覆與加入好友歡迎訊息：

    • 如同投影片介紹，目前不開放也不建議開發者這樣設定。

F 其他注意事項

F-1. 一個請求包含多格訊息格式

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第四件事：LINE平台所傳送的事件是一個陣列) 有更多清楚解釋，歡迎大家去了解一下。 因為 Messaging API 帳號沒有大量的事件訊息傳入，每次所收到事件幾乎都只有一筆資料，所以開發者會誤以為每個事件訊息只需要處理一筆資料。事實上，LINE平台傳送給Webhook伺服器的HTTP請求本體是包括一個或多個Webhook事件物件的JSON格式物件

F-2. Webhook 新增屬性的對應方式

這邊有建議開發者們，對於屬性的判斷上儘量要當成獨立個體之外，對於可能的新增屬性建議也要有比較好的處理方式。 建議方式可以透過 switch case 的方式來判斷，僅僅對於有處理的事件(event) 來處理，其他都略過。

相關文件：

F-3. 關於請求標題中的驗證

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第二件事：驗證訊息來源) 有更多清楚解釋。文章中建議驗證方式如下：

  1. 以Channel secret作為密鑰（Secret key），使用HMAC-SHA256演算法取得HTTP請求本體（HTTP request body）的文摘值（Digest value）。
  2. 將上述文摘值以Base64編碼，比對編碼後的內容與X-Line-Signature項目內容值是否相同；若是相同，表示該事件訊息是來自LINE平台，否則拒絕處理該事件訊息。

相關文件：

G 建議的請求處理步驟

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第三件事：盡快回覆LINE平台正確的HTTP狀態碼) ，在此僅列出相關流程圖，更多內容歡迎各位去部落格查看。

H. GW 伺服器 -> BOT 伺服器的通訊錯誤

H-1. 關於 Error Notification

這部分可以參考以下的流程圖：

這邊是敘述說如果 LINE 平台有問題發生的時候（或是無法正確收到開發者的回覆時），將會另行發信給開發者的信箱中。相關的信件內中如文件上。

參考以下文章：

結論：

以上就是「LINE Bot 開發指南」第二部分的補充與分享，想要知道更多內容可以查看完整投影片，或是找到其他篇的文章來了解。

想了解更多開發者的活動？ 立即加入「LINE 開發者官方社群」官方帳號，就能收到第一手 Meetup 活動，或與開發者計畫有關的最新消息的推播通知。▼

「LINE 開發者官方社群」官方帳號 ID：@line_tw_dev img

Buy Me A Coffee

Evan

Attitude is everything