前言:

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

文章索引:

完整投影片鏈結： 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 的部分。

LINE Developers 相關資源

這邊主要提到兩個網站，分別是：

• LINE Developer Doc:
  • 負責存放所有的相關產品說明文件， API 詳細說明。
• LINE Developer Console:
  • 這就是開發者稱為的控制台部分，跟官方帳號 (Official Account) 的後台不同，這邊主要是負責設定相關的開發資源。 不論是建立新的 Channel 或是新增，修改 LIFF App 都可以利用控制來完成。

LINE Bot 的機制

這一張投影片解釋了一個使用者傳訊息給一個官方帳號後，訊息會如何透貴 LINE 的平台傳遞到開發者的（也就是圖上的客戶端）的 Bot 伺服器。 這邊表達了幾件事情：

• 所有訊息都會透過 LINE 平台的 Talk 伺服器與 Channel Gateway 伺服器處理後傳給 「 Bot 伺服器」。訊息都是透過 Webhook 的方式傳遞，開發者只要依照官方文件開發好像關的 「Bot 伺服器」並且在登入好 webhook 的位置。就可以正確地收到訊息。
• 開發者處理完訊息後，可以透過 API 的方式發送給 LINE Channel Gateway 。 會在依照相關的訊息發送人透過 Talk 伺服器來發送訊息。

相關的開發者文件可以參考：

• Receiving messages (webhooks)

• Sending messages

關於 LINE Bot 與 Channel 之間的相關性

這張投影片解釋了官方帳號與 Channel 之間的相關性，接下來將為讀者詳細解釋:

• 首先使用者對於官方帳號（LINE Bot) 所做的所有動作，都有相關的訊息透過 Webhook 來傳給開發者的 LINE Bot 。
• LINE Bot 收到訊息後，可以透過取得的 Access Token 來通過伺服器認證來發送訊息給使用者。
• 透過 LINE Login 的認證部分也可以將使用者鏈結到相關 LINEE Bot 帳號。（ e.g. 透過網路商城的第三方登入 LINE Login ，可以讓使用者登入網路商城後，也直接加入 LINE Bot ）。
  • 相關部分可以參考文章：

    • 如何透過 Golang 開發 OAuth2 的 PKCE – 以 LINE Login 為例

    • 如何讓 Chatbot 透過 Account Link 來串接使用者體驗 。

此外，這一張投影片也希望帶給各位關於 Provider 的相關概念如下。同一個 Provider 底下的 Channel 拿到的使用者ＩＤ會是相同的，也就是 LINE Login 登入取得的使用者 ID 跟 LINE Bot 上面只要是同一個服務提供者（Service Provider) 是相同的。 也提醒 LINE Login 必須要發佈(Publish)， 才能被所有人使用。（參考 開發者文件： Published LINE Login Channel ) 。

LINE Bot Glossary

關於 Glossary 部分，這邊講解了許多常被詢問的用字。這邊補充一些大家常用字詞。 大家可以針對這份上面的對照表尋找相關用語。 其實有更多的用字在 https://developers.line.biz/en/glossary/ 可以找到。

開發 LINE Bot 的開始步驟/發布前的確認事項

這邊分成兩塊，大家可以參考官方文件上的逐步解釋。

• 在進行開發時： 建議可以參考一下官方文件的說明，這部分已經有中文化了。

  • 開始使用 Messaging API（中文）
  • 建立聊天機器人(中文）。

• 發布給用戶之前，請務必檢查以下內容：

  • 這邊有提到的相關資料鏈結如下：

    • BASIC TERMS AND CONDITIONS OF LINE SERVICES FOR BUSINESS PARTNERS
    • SPECIFIC TERMS AND CONDITIONS OF LINE SERVICES FOR BUSINESS PARTNERS - LINE POINT CONNECT
    • LINE＠Messaging API使用條款

  • 在開發 LINE Bot 的時候請必須要注意到相關條款如下：

    • LINE 服務條款 建議開發者們必須要詳讀 「禁止條款」，避免 LINE Bot 踩到相關禁止條款。

這些相關補充事項，希望每一個開發者都能夠遵守。所有的資料也都請以官方網站的資料為準。

結論：

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

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

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

前言:

前幾天的文章中 [Jekyll] 移除 Disqu 替換到 utteranc 來使用 github issue 作為文章評論 ，我有提到我將本來部落格中的 Disqus 評論有搬到 https://utteranc.es/ 的過程，但是在 Disqus 裡面還有接近兩百個留言 (共有 189 個留言，分別在 55 篇文章內) 怎麼辦？

秉持著自己打造自己用的小工具原則（ –關在家裡太無聊– ），就寫出了這個小工具來使用，希望能幫助到一些人。 也希望有更多的人一起加入開發相關功能。

TL;DR

本篇文將要介紹以下一些的部分，除了介紹如何使用外。人和

• 如何導出 Disqus Comment
• 套件: Disqus to github issue Go 
• 包括哪些功能
• Disqus XML Format 解析
• Github issue created in Go
• 結論
• 成果
• 參考文章

如何導出 Disqus Comment 到 Utteranc

• 到 Disqus 管理介面，去導出： http://disqus.com/admin/discussions/export/ 。
  • 大概需要過一兩天才會收到導出的檔案（不定時）。
• 到 Utteranc 設定導入
• 修改 Github Page 設定。

可以參考文章 [Jekyll] 移除 Disqu 替換到 utteranc 來使用 github issue 作為文章評論

套件: Disqus to github issues Go

https://github.com/kkdai/disqus-to-github-issues-go

• 安裝套件方式：``go get github.com/kkdai/disqus-to-github-issues-go`
• 並且提供一個 CLI 給大家先用，大家可以安裝 go install github.com/kkdai/disqus-to-github-issues-go/cmd/import_disqus_cli

相關指令：

• -f: Import disqus exported xml file. (get from http://disqus.com/admin/discussions/export/)
• -u: github user name, you want to use for post github issue.
• -r: github repo name, you want to use for post github issue.
• -t: github token, you can request your from https://github.com/settings/tokens.

使用指令範例：

./import_disqus_cli -f="EXPORTED_XML_FILE" -r="BLOG_REPO" -u="GITHUB_USER" -t="YOUR_TOKEN"

包括哪些功能

• 讀取從 disqus export 的 XML file. (可以參考格式範例在 github )
• 列出所有的 Comments
• 列出所有文章（標題，作者，時間）
• 導入到 github issues (使用 utteranc 格式)

接下來會針對幾個部分放上相關程式碼，希望讓大家分享如何寫。

Disqus XML Format 解析

這是簡單版本的 XML Parser，大家可以收到 XML 之後將檔案丟到 XML to Go 就可以取得格式。

其中比較需要解釋的如下：

• Articles: (xml tag: thread) 這邊指的就是原本的文章。他跟留言是一對多的關係。（一篇文章內可以有個留言）
• Comments: (xml tag: post) 這邊是流言，資料比 Article 還後面需要另外做出 Mapping Table 來鏈結。

Article 與 Comments 連接關係為： Comment.ArticleLink.ID 跟 Article.AttrID。

如何作出準備 Import github issue 的資料

目前採取方式是根據在 Githib Issue 的 title 當作 key ，來做 map 。

如果以 path 來當 title ， ` mapping := make(map[string] Issue)` 來管理，可以很快速的透過 Map 來尋找到相關的資訊。

留言排序

其中，每一篇文章的留言是需要排序的。為了確保留言可以在年度順序下呈現。需要相關 Sort 的準備如下：

透過準備 Sort Interfaces 的方式來讓 []Comment 支援 Sort()。

Github issue created in Go

關於發送 Github Issue 的部分，使用的是 Google 開源的 golang 套件。 https://github.com/google/go-github ，這邊記得要使用最新的版本（筆者時間最新版本是 v35）

import (
   ...
	"github.com/google/go-github/v35/github"
	"golang.org/x/oauth2"
)

相關程式碼如下：

其中 gIssue, _, err = client.Issues.Create(ctx, b.User, b.Repo, input) 後會取得建立好的 Github Issue 相關訊息，需要相關的 ID 來後續加入 Comment 。

這一段程式碼，其實對於許多開發者想使用 Github Issue 作為資料管理的方式可以參考（聽說有人拿 Github Issue 來當 DB www) 。

成果

最後執行過後，可以將 Disqus 的留言全部整合進 Github Issue 之中，並且可以保留相關時間。也可以在部落格裡面正常的呈現。希望這個工具能夠幫助大家。

結論：

本文分享了關於 Disqus 的輸出資料格式分析，並且分享了如何在 Github 上面建立 Issue 的相關程式碼。整合起來其實並不難，但是許多時候這些應用往往會變得很有趣。 大家可以參考筆者前一篇文章: [TIL] 為了自己的習慣，弄了一個簡單的服務 Github issue bookmark。

相關文章：

• Removing Disqus and adding GitHub Issue Comments

• Golang time doc

• https://github.com/goreleaser/goreleaser

• https://github.com/settings/tokens

• [TIL] 為了自己的習慣，弄了一個簡單的服務 Github issue bookmark

什麼時候是好時候：掌握完美時機的科學祕密
When: The Scientific Secrets of Perfect Timing

作者： 丹尼爾・品克  
出版社：大塊文化 
出版日期：2018/05/29 

買書推薦網址：

• 電子書: Readmoo

• 博客來: 購買網址

前言:

這一本是今年所讀完的第六本書。你知道透過大數據統計的狀況下，大部分的人什麼時候喝咖啡最好？ 什麼時候做文件處理的事項最好？ 什麼時候是最容易發生轉職跟轉換工作的季節？ 這本書分享了許多統計上的相關數據，讓你了解時間所帶來的秘密，並且也根據每個人工作上的習慣，來建議什麼時候做回覆電子郵件的事情最好，什麼時候建議拿來開會與發想事情？

這本書作者之前看過他的書： 動機、單純的力量(DRIVE: The Surprising Truth About What Motivates Us) ，所以對於他這一本書相當的期待。

內容簡介與心得:

我們無時無刻都面臨一連串永無止盡、與「時機」相關的決定。什麼時候換工作，什麼時候安排課程，什麼時候步入穩定關係或全心投入專案。然而，我們卻隨意做出這些決定——基於直覺、預感及猜測。在本書中，丹尼爾．品克認為這是完全錯誤的方法。

根據品克的話，我們都知道時機就是一切，但我們對時間本身卻了解不多，以為時機是種藝術。他在書中表明，時機其實是一門科學，於是寫出這本談論「什麼時候做什麼事」、有關「時機」的書，為我們揭開時機的科學祕密：

•早上何時喝咖啡最好？——不是起床後立刻喝，最好的時間點是在起床後1～1.5小時喝。
•工作多久應該休息一下最有效？——每工作52分鐘，休息17分鐘。
•包含新年元旦，一年當中你有幾天可以重新開始？——86天。
•怎樣利用一天中隱藏的模式來建立理想的工作時間表？
•為什麼有些特定類型的休息，會顯著提高學生的考試成績？
•什麼時候是辭職、轉職、或結婚甚至離婚的理想時間？

品克借鑑心理學、生物學、神經科學和經濟學等豐富的研究成果，提煉精華，彙整成引人入勝、深具說服力的文章，字裡行間充滿魅力無窮的故事，以及實用的要點——集結在每一章的「時間駭客指南」中。本書富含宏大觀念與深遠寓意，將改變你對自己過去、現在及未來的想法，同時助你掌握人生各階段面臨時機抉擇的最佳決策。

章節條列

第1部　一天

首先透過心理學與生物學的角度來分析，上班族一天的情緒波動。會發現中午吃飯是一個很大的分界點。許多的人專注度在上午最高，但是中午吃完飯回來辦公室後，就開始逐漸下降到下班才會回覆。 還有快樂的心情也是如此，透過這些方式來提供給讀者們知道，該如何尋找人開會，該如何將工作事項做有效的排列與準備。

接下來透過慕尼黑時間型態問卷 (https://www.danpink.com/MCTQ/) 來判別每一位讀者屬於哪一種的人，那麼這樣來說他一天得時間會如何安排。

• 雲雀
• 第三種鳥
• 貓頭鷹

其中雲雀是指的是早起的人們，而貓頭鷹完全相反的是晚起的人們，最後一種就是介於其中的人（大部分也是第三種）。

接下來探討的中午休息（午睡）帶來的工作相關影響，這部分蠻有趣的，其中午休可以帶來下午的充沛活力也是不能不注重的。其中建議的就是小睡 10 ~ 20 分鐘是最建議的休息長度。 下午之後，也建議有所謂的「微休息」，讓專注度可以快速地透過休息後來回復。

第2部　開始、結尾與中場

開始：

將時間從一天放長一點，放到整個職涯，整個人生或是幾年來說。什麼時候會是最被重視的時間？ 就是一個新的專案的啟動，一個學習開始，甚至是一個新的工作的開始。 本書作者相當建議讀者要做「事前的驗屍」，也就是在一開始先訂定專案的成功，失敗的可能性，先預想各種可能發生的大型危機。

中場：

人們總是習慣在一開始的時候戰戰兢競，但是過了一半之後就出現了所謂的「中間點危機」（放大到人生，叫作中年危機）。 本書也分享了哪一些時間容易發生轉職的危機，中間點容易發生疲倦與厭煩感是既定的事實，該如何調適也是一門大學問，作者有其他建議方法：

• 設定暫時性目標： 將中間幾個點設定成小目標，全力衝刺。
• 公開宣示暫時目標: 告訴其他人你將要完成事項，讓大家一起來給你壓力，讓你能夠做完它。（這也是我最常使用的方式，笑！）
• 話說到一半就停：這邊說得是，你不要把中間事情做到一個段落，而是每一件事情都做到一半，才會讓你有繼續的動力。
• 不要讓鏈子斷掉： 回頭看看你過往的努力，會讓你更有信心跟毅力能夠往後。
• 想像這麼做可以幫助其他人： 往往許多事情是不是只有你自己，很多時候你的工作會帶給其他人很深遠的影響。

結尾：

人們對於中年後的朋友開始去蕪存菁，也會慢慢對於自己想要深交的人開始篩選，這些都是結尾容易發生的事情。 甚至也分享了許多人在工作的最後幾天也往往最讓人印象深刻，甚至是人生的末期也讓人印象深刻。 所以結尾的力量其實相當的重要且深遠。 其中有句話我印象很深刻：

皮克斯每一部的電影主角都有一個想要達成的目標，但是他會明白這個目標其實不是自己需要的東西。而這個目標往往會讓他放棄他需要的事情：朋友，家人。最終主角都會放棄原來的目標，真正的追求他們原本就擁有的東西。 結果層次最高的情就是在這些背後的心理轉折。核心在於這種錯中複雜的情感。

第3部　同步與思考

接下來探討的是群體的時間點，同步與思考的部分。 要如何在整個團體能夠同步到一個最佳的狀況呢？ 比如說合唱團要如何抓準時間表演？ 龍舟隊伍要如何才能同步大家划船的力量往前衝刺？ 擴大到整個組織要如何抓到好的時間點。讓整個團隊能夠在合諧的狀態？

首先作者介紹了一個印度的奇特行業： 幫人送新鮮的午餐便當到手上的工作，在印度首都有許多的人，到每一個人家中收取剛剛包好的便當，送到工作人員的手中。這些人代表的中午吃飯的重要，也代表著一份情感的傳遞。 他們分工也很精密，收送的人，跟發放的人如何有默契的交接，讓便當可以快速的到人的手上，不會冷掉。 這些和諧的團體會有一種同步的機制與節奏，就是「同步者的快感」。

團隊中協調技巧：

• 快速回覆電子信件
• 分享彼此的奮鬥故事
• 培養自律的團隊儀式
• 由每個人都提供一點點的拼圖方式

最後作者也分享一些名言：

以前我相信，時機就是一切。現在我相信，任何事情都有其時機

心得:

「什麼是好時機？」，我們常常在問自己這個問題。 這本書讀到一半的時候，會以為很像是心理學或是生物學的建議書籍。但是隨著書本內容的案例分享與許多有效與睿智的「時間駭客」精髓，作者除了分享時機的重要性之外，更分享了如何在每個時間中，讓事情的效果發揮到最大。 這一本書有實際的建議，也有相當程度的整理與統計，讓你可以更有效地接受相關的概念，相當建議可以看看。

參考文章

• 讀書心得-動機、單純的力量(DRIVE: The Surprising Truth About What Motivates Us)

前言：

疫情升溫打斷本來出遊計劃，還好女兒很乖在玩。 那我就來弄弄 Jekyll 的評論搬遷，結果發現最近有個好用系統 utteranc.es 可以讓你直接使用 github issue 來作為文章評論。 來看看吧。

本篇文章將告訴你如何移出，並且使用 Github Comment 作為文章評論用，現在也有個開源好用的工具。 https://utteranc.es/

什麼是 Disqus

一直以來本站是透過 Jekyll 來架設的，之前本來有使用 Disqus 作為文章評論系統，雖然很多人說廣告太多，太慢。只是覺得還好，可能沒仔細看。 最近覺得 disqus 的廣告越來越嚴重，影響整個效能。決定拿掉了。 有需要參考的可以看一下這個 commit 主要就是先註解掉相關的設定。 然後發送 git push 即可。

移除 diqus

大家可以參考這個 commit. https://github.com/kkdai/kkdai.github.io/commit/3dfba4885874cb1cb0c06a09fd2f4fffd892623a

主要就是把 disqus 的設定拔掉。

highlighter: rouge
markdown: kramdown
#disqus: evanlin1007

#comments :
#    provider : disqus
#    disqus :
#      short_name : evanlin1007

加入 utteranc

utteranc 是一個完全 Open Source 並且使用 github comment 。並且提供一些設定，還有外觀的 theme 可以設定。感覺相當好用，社定上也很簡單：

• Install for your github app
• Put code in your Jekyll
• Done ! (搭啦)

參考 https://github.com/kkdai/kkdai.github.io/commit/b9606abd93c08bf131efa4db78c8762e8a26f1da 可以修改 _layouts/post.html 如下：

<script src="https://utteranc.es/client.js"
        repo="kkdai/blog"
        issue-term="pathname"
        theme="github-light"
        crossorigin="anonymous"
        async>
</script>

完成品：

這樣是不是很快速（五分鐘就好了）

代辦事項：

接下來就要把 disqus 的評論搬到 github comment， 這邊可以先 export 出來後，寫個 Golang 來 import 。找到了在這裡： http://disqus.com/admin/discussions/export/

接下來就是把文章評論搬過去。

參考文章：

• Removing Disqus and adding GitHub Issue Comments
• Enabling Jekyll Blog Comments with Utterances
• 我的相關 commit:
  • 拔掉 Disqus https://github.com/kkdai/kkdai.github.io/commit/3dfba4885874cb1cb0c06a09fd2f4fffd892623a
  • 增加 utteranc https://github.com/kkdai/kkdai.github.io/commit/b9606abd93c08bf131efa4db78c8762e8a26f1da

前言:

在 2021/04/09 的新聞上， LINE Login 支持了 PKCE (Proof Key for Code Exchange) 的流程。 本篇文章將清楚地解釋一下，什麼是 LINE Login ？ 為何 LINE Login 需要支持 PKCE ? 最後會透過一個範例，帶領著讀者們一起來導入與體驗 LINE Login with PKCE 。

其中本篇文章的程式碼分為三個部分，以下快速說明：

• LINE Login Go SDK:
  • Github: github.com/kkdai/line-login-sdk-go
• LINE Login Starter:
  • GitHub: github.com/kkdai/line-login-go
• LINE Login PKCE Starter:
  • GitHub: github.com/kkdai/line-login-pkce-go

TL;DR

本篇文將要介紹以下一些的部分：

• 什麼是 LINE Login? 什麼又是 OAuth ?
• 什麼樣的情況會建議使用 LINE Login?
• LINE Login 的流程
• OAuth2 有什麼樣的缺點?
• 什麼是 PKCE?
• 如何在 LINE Login 之中導入 PKCE?
• 結論
• 參考文章

什麼是 LINE Login? 什麼又是 OAuth 2.0 ?

許多的商業服務都會透過會員機制來提供許多專屬的優惠或是獎勵活動，但是會員的註冊與登入流程常常讓許多使用者覺得為難。除了要填寫許多的資料外，使用者還需要額外記住另外一組的帳號密碼。 LINE 在台灣的佔有率相當的高，並且幾乎每個使用者都有 LINE 的帳戶的狀況下，這時候如果能夠直接使用 LINE 帳戶來註冊與登入網站服務的話是不是相當的方便？

LINE Login 除了提供一個方式來登入之外，也可以提供使用者名稱，大頭照的相關資訊。並且透過 LINE Login 也可以同時讓使用者加入商業服務的 LINE官方帳號，讓使用者更無時無可都可以使用到相關的服務。

什麼樣的情況會建議使用 LINE Login

這裡會條列出哪些情況建議需使用 LINE Login 作為讀者來評量自己有沒有需要使用 LINE Login :

• 剛開始要建立電子商務服務或是網站，想要減少使用者註冊的時間並且快速加入。
• 想要推廣自身官方帳號的聊天機器人服務。
• 就算是已經推廣一段時間的電子商務服務，但是想要透過 LINE 來接觸不同的客戶群。

了解為什麼使用 LINE Login 以及甚麼狀況下建議使用之後，接下來就引導讀者如何使用範例程式碼

範例程式碼

https://github.com/kkdai/line-login-go

如何部署範例程式碼:

• 到 LINE Developer Console 建立相關的 Provider 跟 Channel。
• 建立一個 LINE Login 的帳號，並且將以下兩個資訊記住:
  • Channel ID
  • Channel Secret
• 另外建立一個 LINE@ 並且打開 MessageAPI 的功能（也就是建置 chatbot 用），並且將以下兩個資訊記住:
  • Channel Secret
  • Channel Token
• 到 https://github.com/kkdai/line-login-go 按下 Heroku Deploy ，建立該帳號並且部署該服務。這時候會要輸入三個資訊:
  • LINECORP_PLATFORM_CHANNEL_CHANNELID
    • 填入 LINE login channel ID
  • LINECORP_PLATFORM_CHANNEL_CHANNELSECRET
    • 填入 LINE login channel Secret
  • LINECORP_PLATFORM_CHATBOT_CHANNELSECRET
    • 填入 Chatbot channel Secret
  • LINECORP_PLATFORM_CHATBOT_CHANNELTOKEN
    • 填入 Chatbot channel Token
  • LINECORP_PLATFORM_SERVERURL
    • 這個資訊根據你的 heroku app 名稱來決定，假設你的 Heroku app 名稱叫做 test-api-1234 那麼你就該填 https://test-api-1234.herokuapp.com
• 回到 LINE Login 的帳號設定，[App setting] 將以下位置寫入 callback URL https://test-api-1234.herokuapp.com/auth
• 回到 LINE chatbot 的帳號設定，記得把 https://test-api-1234.herokuapp.com/callback 加到 LINE chatbot web hook 才能正確地啟動聊天機器人。

LINE Login 的流程

(使用 Profile (也就是 OAuth 2.0) 方式來讓使用者透過 LINE Login 之後取得使用者資訊)

LINE Login 提供了兩種方式來讓開發者可以安全地取得使用者資訊：

• OAuth 2.0 authorization code grant flow (opens new window)
• OpenID Connect

兩種方式的不同點在於開發者可以再請求 scope 的時候標注是透過 openid 或是 profile 方式來索取相關資訊。

以下的內容均參照 Integrating LINE Login with your web app

• (1). 首先瀏覽器訪問該網站 （假設你直接使用 https://login-tester-evan.herokuapp.com/)，進入了 browse() 顯示出三個 LINE Login 按鈕。
• (2). 使用者按下了 LINE Web Login 的話，就會進入 gotoauthpage() 直接產生一組 API URL 直接導向到 https://access.line.me/oauth2/v2.1/authorize 。這邊其實有一些參數可以設定，可以參考 LINE Login 參數設定。
• (3). 使用者這時候會連到 LINE Platform 來進行登入的步驟，不論是透過 App 登入還是輸入帳號密碼的登入方式。登入完成後會透過 redirect_uri 網址的位址傳回一組 code ，作為使用者資料的存取之用。 這時候會呼叫到 auth() 來解析 code 。
• (4). 在同一個 auth() 之中解析 code, state, 與 friendship_status_changed 後，檢查 state 正確性之後。就可以透過 code 去抓取使用者的資料了。 這時候會呼叫 https://api.line.me/oauth2/v2.1/token 的 API ，相關必要參數也可以參考這個網址。
• (5). 一樣在 auth() 之中，回傳的結果可以得到 id_token ，透過 id_token 需要透過解譯的方式來將它還原成使用者的資料。這邊也已經包裝好為 DecodeIDToken()
• 透過 DecodeIDToken() 就可以得到使用這名稱與大頭照。 (email 需要額外申請)

以上就是一般的電子商務網站的導入流程。

OAuth2 有什麼樣的缺點

在 OAuth2 提出後， Google 也在 2015 Google 提出的 RFC 7636中也提出了一些值得考量的點。 本篇文章有提到在手機端的 App 如果導入了 OAuth2 的流程中，有可能傳輸過程中被其他惡意安裝的手機 App 竊取相關資訊。 相關細節可以參考 LINE Login 官網提供的詳細案例。

（詳細說明，請參考 Benefits of implementing PKCE for LINE Login)

這裡稍微跟大家說明相關的流程與發生的問題：

• 使用者透過手機上有串接 OAuth2 的 App 來做 Authorization
• 進入 OAuth2 服務提供商的帳號登入畫面
• 認證完成後， OAuth2 平台會根據當初登記的 URL （手機上為某個登入的 URI Scheme) ，開啟相關 App。
• 這時候，如果有使用者不小心安裝了惡意的 App ，他可以登記同一個 URI Scheme ，但是因為手機設計原理兩個 App 都會收到相關的 URI Callback 。
• 惡意程式(Malicious App) 收到 URI Callback 呼叫並且取的 code 與 state 並且透過其他方式取得 Channel ID 跟 Channel Secret (原理透過 App 掃瞄，這裡就不詳細敘述)。
• 這時候，取的 code 與 state 的惡意程式，就可以透過呼叫 GetAccessToken 取的相關 Token 並且獲得權限。

由於原先的 OAuth2 在 client App 端有這樣的缺陷，所以透過 PKCE 的方式可以來補救相關問題。

什麼是 PKCE?

(from LINE Login 導入 PKCE in LINE Login 的流程示意圖)

PKCE (Proof Key for Code Exchange) 是由 Google 在 RFC 7636 提出的 Code Exchange 機制，透過這樣的交換資訊方式。可以避免中間透過 Callback URI 所造成的竊取攻擊。 詳細的方式敘述如下：

先解釋兩個參數:

• Code Verifier: 一個特殊字串，長度限制為 43 ~ 128 之間。
• Code Chanllenge: 透過 SHA 256 將 Code Verifier 轉換過的字串。

接下來要解釋一下，這兩個字串如何能夠讓 OAuth2 的流程中安全性增加。由於 SHA256 是不可逆且較安全的加密模式，並且在資料的傳輸上先提供 Code Chanllenge 再來是 Code Verifier 可以確保著交握的兩端都是同一個人，因為必須要同時都有兩個才能正確地確認。 這樣就算原本的 code 被竊取到了，也會因為無法產生正確的 Code Verifier 讓惡意程式無法竊取到資料。

那麼詳細的 LINE LOGIN withg PKCE 流程如下：

• 產生 Web Login URL 的時候，先丟 Code Chanllenge 在傳遞參數中。
• 連接到 LINE 開始認證流程，完成認證流程後。透過 Callback URI 傳回 code 與 state 。
• 這時候認證方會將 Code Verifier送給認證伺服器來取得 Access Token 。
• 認證伺服器端會拿 Code Verifier 與 Code Chanllenge 來確認，是否是同一個需求端發出的需求。
• 返回 Access Token ，完成認證跟取得資訊的需求。

如何在 LINE Login 之中導入 PKCE?

接下來會使用 line-login-SDK-go 與 LINE-login-pkce-go 兩個範例程式碼來展示：

• LINE Login Go SDK:
  • Github: github.com/kkdai/line-login-sdk-go
• LINE Login PKCE Starter:
  • GitHub: github.com/kkdai/line-login-pkce-go

如何產生 Code Verifier

如何產生 Code Challenge

文件上面有提供 Code Challenge 的 python psuedo code ，這邊將其轉換成 Golang 的程式碼。 主要比較複雜的部分是 sha256.Sum256() 跟字串要做 URLEncoding 處理。 主要要根據 Base 64 Encoding with URL and Filename Safe Alphabet (opens new window) 的處理方式來做。 其實在 Golang 只要一行就可以搞定了。

產生 Web Login 網址

這一段程式碼則是利用 github.com/kkdai/line-login-sdk-go 所產生的網頁轉址的程式碼，主要就是產生 codeVerifier 與 codeChallenge (Global 參數)。請注意，在 SPEC 中，每一個 Web Login request 的 codeVerifier 與 codeChallenge 都需要是不同的，才能確保資訊的安全。

要求 Access Token 的程式碼修改

這裡只需要注意的是， codeVerifier 需要傳遞正確的，不需要重新產生即可。

展示

這邊有個簡單的展示網站，也歡迎想了解如何開發的開發者們，可以直接使用以下的開源程式碼。 範例程式碼提供兩種模式的來取得使用者的登入資料。

• OpenID: 透過 OpenID 的格式，直接登入完成後，取得使用者登入資訊的 JWT 。並且提供相關解析的程式碼。
• GetUserProfile: 透過取得 User Access Token 的方式，呼叫 Get User Profile 來取得登入使用者的資訊。

更多的程式碼，歡迎參考。

LINE Login PKCE Starter:

• GitHub: github.com/kkdai/line-login-pkce-go

結論：

許多開發者在開發 Web App 的時候，最麻煩的往往是使用者資料的註冊。 因為複雜的註冊流程與多一個帳號密碼往往會讓使用者卻步。 LINE Login 提供良好的機制可以讓許多開發者使用到國內最多人使用的 LINE 來登入，節省掉許多開發上的麻煩。 本篇文章介紹了新的登入機制: PKCE for LINE Login 。 讓登入機制符合最新的安全機制外，更可以讓使用上沒有開發後顧之憂。 並且提供相關範例程式碼x，讓開發者可以無痛的導入最新的機制。

相關文章：

• LINE Login now supports PKCE

• RFC7636 - Proof Key for Code Exchange by OAuth Public Clients

• RFC7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

• RFC6749- The OAuth 2.0 Authorization Framework

• Developer News: LINE Login now supports PKCE

• Developer Doc - PKCE support for LINE Login

• OAuth 2.0 in Go

前言:

最近 Google Taiwan 開啟一個計畫「Android App 開發培訓計劃 2021」，透過 Android Studio 跟著 Kotlin 這個語言來讓大家寫 Android App 。趁機順便學習一下 Kotilin 相關語法跟需要注意的地方。

相關工具

Kotlin Playground

由於有點懶得安裝環境跟相關的 IDE 設定，所有的練習其實可以快速的在 Kotlin Playground 上面完成。

語法Tutorial - Koans

可以透過網頁上面的 Koans 或是內建在 JetBrains IntelliJ IDEA or Android Studio 的 JetBrains educational plugin

學習建議：

由於這個語言我不是很熟習，但是熟悉新的語法其實蠻建議透過 Tutorial 來先有個概念性的了解，方便你開始相關的查詢。 所以這邊建議先跑過一次 Koans 再來把相關資料結構與語法來做一個語法的相關脈絡整理。

特別資料結構語法說明

LIST

val numbers: List<Int> = listOf(1, 2, 3, 4, 5, 6)

透過 List 關鍵字來加上 generic type 來建立出相關 List 物件。也可以透過 Inferred 方式建立。

val numbers = listOf(1, 2, 3, 4, 5, 6)

Kotlin 是 Zero-based Index 的語言（延伸自 Java) 。

MutableList

參考官方文件 ， MutableList 為長度可變的 List 。也就是可以針對 List 去 add, addAll, listIterator, remove, removeAll… 相關操作。 宣告方式參考如下：

val entrees = mutableListOf<String>()

相關文章：

• Stackoverflow: You have not accepted the license agreements of the following SDK components duplicate