.NET Walker

本篇部分內容已過時，請閱讀完後再接續看新版 v2.1 API參考: http://studyhost.blogspot.tw/2017/12/clinebot17-line-login-v21.html 上一篇 寫完之後，我心裡想，我連Line Notify都寫了，那沒理由不寫Line Login吧，雖然，我猜不一定很多人對這個主題有興趣。 而且我覺得，要寫這個主題，我應該要先多寫一篇關於 oAuth和SSO (Single Sign On)的文章才行，否則我覺得大半讀者可能如同到了北京一般(伸手不見五指)…不過，oAuth和SSO有空再寫，我先趁記憶猶新，把Line Login整理一下。(補充:後來寫了，請參考 這裡 ) 背景與用途 : 基本上Line Login是讓網站或手機App開發人員做用戶身分識別(Identity)與單一登入(SSO)用的，也就是說，網站或手機App開發人員，不需要自己管理會員帳號密碼，可以透過Line Login這個符合oAuth標準的Identity機制，來進行用戶的身分驗證與個資取得，以達成單一登入。你一定曾經用過某些網站，在登入或註冊帳號的時候，並非要你填入新的帳密，而是連結(整合)到Google帳號或是微軟的Microsoft Account，即可完成身分驗證與登入。 這有什麼好處? 對用戶來說: 不用記得很多組帳號密碼 對網站或手機App開發人員來說 不用費心保管個資，由oAuth Provider(例如Google、以及本文要介紹的Line Login)幫你管理。 不用管個資，就沒有被竊的風險。 如果你有多個網站或服務，倘若都支援某一種驗證方式(例如Line Logic)，則用戶登入了A網站，當連結到B網站的時候，無須再次登入(此即為SSO)。 好，我當作各位都知道了，如果對於oAuth或SSO還有疑問，以後有機會我再說明。我們先來看，要怎麼將你的網站連結到Line Login… 順帶一提，其實一直以來，Line的各種動作都看得出Line的企圖心不小，目前提供oAuth的廠商，幾乎各各是大廠，Google、微軟、Yahoo、沛米(不認識? 這是我投資參與的公司)…Line在這個領域要衝進來當玩家，很是任性… 註冊Line Login 在使用這個服務與你的網站整合前，你必須先註冊

前面 我們討論到了很多跟Line Bot有關的機制，但有朋友提了一個問題，如果我單單只是要透過程式碼發訊息給用戶，一定要申請並建立一個Line Bot嗎? 其實不用。 一直以來，有一個比較不被重視的機制，叫做LINE Notify，其實它已經誕生很久， IFTTT 的Line通訊整合，就是用LLINE Notify做的。 LINE在 TectPulse 中，對LINE Notify的定義是… 第三方服務提供商可以利用 LINE Notify 套件開發通知型的應用，讓外部網站的服務和應用能透過 LINE Notify 官方帳號傳送純文字、貼圖或圖片式的服務通知給用戶，例如天氣預報、貨到超商請取貨、匯款成功、交易完成等。LINE Notify 就像一般的聊天機器人一樣可以加入一對一的對話視窗中，也能加入群組中。 他這樣講你聽得懂? 聽得懂就好…ㄟ…不懂也沒關係，我稍微翻譯一下。 簡單的說就是，如果開發人員(或店家、或企業)只是想要發通知給用戶，或和用戶進行基本的互動，那倒也不一定需要自己申請一個Line Bot(因為未來用戶可能得要加入很多Line Bot，收到很多不同單位傳來的訊息，這樣用戶會很煩，最後把你的Bot封鎖，或是根本忘了它，而且，商家(開發人員)申請Line Bot來發Push訊息，如果量多的話，要付很貴的$$$)，但若你用現成的LINE Notify，其實也可達成此功能(而且FREE，對，免費!!!)。 LINE Notify就是底下這個… 其實，它就跟一個Bot一樣，你根本可以把它想成一個商家共用的Bot(而非自己獨立建置的Bot)。它一樣可以發訊息給你的用戶，你只要能夠Access這個Line Notify Bot，就可以透過它來發送訊息。 怎麼做呢? 首先，你還是要申請一個Line Notify的服務，基本上就是取得Client_id與client_secret。申請網址在底下: https://notify-bot.line.me/zh_TW/ Line把這個申請藏得很好，請拉到最下面，找到…『登錄服務』: 你看，這藏得多麼隱密啊。 點選後用你的Line帳號登入，會出現底下的表格: 請妥善填寫，然後按下『同意並往下一步』。填寫的重點只有兩個: 服務名稱和服務圖片，會出現在Line Notify用O

你沒聽錯，事實上asp.net WebForms也能走SPA(Single Page Application)的開發架構，並且跟在前端的Bootstrap與Vue.js框架搭配得很好。 技術的使用存乎一心 記得曾經對學員說過，不管你用哪一種開發方式，只要對開發技術有足夠的熟悉，並且瞭解基本原理與前因後果(再說一次，學習時， 為何 永遠比 如何 重要)，那實在無需追逐潮流，你依舊可以在技術變遷中掌握到重點。 曾經聽過有些開發人員從WebForms轉換到MVC走了一條坎坷的路，並且轉換的理由很是讓人莞爾，這邊略過不提。但我想說的是， asp.net的MVC和WebForms走的是兩條截然不同的架構路徑，兩者並沒有取代性的問題，千萬別誤以為MVC主要目的就是用來取代WebForms用的 。 順帶一提，那我認為什麼是真的有取代性的? 舉個例子，物件導向程式設計幾乎取代了結構化程式設計；資料庫存取的ORM技術，幾乎取代了ADO.NET等非ORM的資料存取技術；C#中的Linq取代了傳統的物件查找方式。這些，則是有取代性的… 所以，這一路上曾經聽過有些開發人員從WebForm轉換到MVC卻走了不少冤枉路， 然後換到MVC之後卻用和傳統ASP一樣的思維在開發系統，這樣換比不換更慘 。 如何在asp.net WebForms中實現SPA? 警語 : 接下來的內容很是驚悚，如果你對於asp.net WebForm或是MVC的『標準寫法』有著異於常人的堅持，不容妥協，那請自行斟酌，小心閱讀這篇。 還記得我們先前曾經說過的嗎？SPA對我們團隊來說的價值是『 沒有任何從伺服器端Render HTML到前端的行為 』，這麼做有哪些好處，在 前面 我們已經多次的提到過。 但整個WebForms的架構根本就是從伺服器端Render一堆的HTML到前端啊，這架構怎麼會符合SPA呢? 是的，這沒辦法，因為WebForms生來就不是走SPA路線的，在WebForms誕生的那個年代，根本還沒有SPA的影子。整個WebForms的行為都是在模擬傳統的Windows物件導向程式設計，因此任何的WebControls，舉凡Button、InputBox、DropdownList…全都是透過後端的HTML Render Engine動態產生的。 這導致，如果你用了任何WebContro

這幾天我們更新了Nuget Package LineBotSDK ，加上了一組非靜態的bot類別，現在你可以透過底下這段程式碼，直接建立一個bot物件實體，來操作所有有關發送Line訊息、或是圖片、貼圖…等工作… 注意上面這段程式碼，其中的圖片URI必須是 https ，否則會發生錯誤，圖片支援.png的格式(估計其他也支援，但我沒試)。 透過物件實體(Object instance)來操作，省去了呼叫PushMessage的時候一直要傳遞AccessToken的不方便，同時在記憶體管理上也比較安全。 這組bot類別還提供了傳送貼圖的功能，例如: 上面這段程式碼可以發送出底下這樣的貼圖: 為何傳入packageId與StickerId參數 1 , 2 是出現上面這個貼圖呢? 目前LineBot可以用的貼圖就那幾組，請參考底下連結: https://devdocs.line.me/files/sticker_list.pdf   上面這個連結顯示出了目前有可以用的PackagId與StickerId。 別忘了，使用上述的功能必須先在你的專案中加入最新版(0.3.9)的LineBotSDK喔: OK，盡情的傳送貼圖吧，Have fun~ ---------------------- 相關課程: http://www.studyhost.tw/NewCourses/LineBot

前面 我們談過了非技術的背景原因之後，我們在這篇會正式開始跟各位介紹我這幾年在團隊中最常使用的開發架構。在大部分(超過九成五)的Web開發情境下，最近幾年我們多半採用SPA(Single Page Application)架構。這邊我們先定義一件事情，有些人覺得(認定)SPA就一定只有一個html page，整個應用程式就都在這個page當中運行，所有的功能都在這個頁面上呈現，所以也沒有換頁這件事，但，對我們來說並不是這樣的。 SPA概念在.NET或非.NET陣營上都有著不同的定義，但對於我們團隊而言，其重點在於『 沒有從伺服器端動態Render HTML到前端 』的這個動作，伺服器端與前端Browser之間的交互，只有幾個行為: 下載靜態HTML Pages(大多時候都不只一頁) Client(Browser)與Server(WebAPI)之間的Http Call與JSON傳遞 前端頁面也幾乎沒有Form Submit這個動作，取而代之的是AJAX非同步呼叫。 that’s all. 這樣的規範(你要說是限制也行)讓開發架構變得非常單純，應用程式很自然地分成了三層: Presentation Layer(view)，採用HTML+javaScript ， 運行於用戶端Browser Service Layer，採用asp.net WebAPI或PageMethods，運行於伺服器端IIS Business Logic Layer，採用C#寫成的class，運行於伺服器端Application Server或IIS(和Service Layer佈署在一起) 為何不用任何『從伺服器端動態Render HTML到前端』的機制? 伺服器端只對前端傳遞JSON與靜態HTML(而非透過C#程式碼動態生成的HTML)，這是一種限制，但這個限制利大於弊，所有透過伺服器端往前端Render HTML的技術(ASP、PHP、ASP.NET WebForms、ASP.NET MVC View)，一不小心都很容造成相依性、並且導致重用性降低，因為開發人員會忍不住把Business Logic寫在其實是Render View的展示層程式碼中(如果你曾經在MVC的Controller或是WebForm的Page裡面寫存取資料庫或撰寫運算的code，那就是了)。你很難

講技術之前，先讓我說說最近發生的幾件事情… 這時代沒有什麼趨勢好說的… 前些日子，我在某個研討會當中，碰到一位學員，他在上課前找到了我，搶先問我先前提過要開的架構設計課程，最近一次何時會開呢? 我很高興他對這個課程有興趣，但是卻只能黯然地跟他說，今年實在不一定有空了。 除了時間的因素之外，其實也因為有另一個顧慮，就是這幾年的資訊科技變化實在不小，在頻繁的變化當中，要建構出相對穩定的架構確實不易，也因為有感於此，在這場研討會中，我很猶豫的要不要提更多我對於這幾年技術變化自己的看法。 別忘了技術的最終目的永遠是應用 前陣子有位大神問了我一個問題，當然，大神的功力都是很強的，問的問題當然也讓人無法小覷，所以沒多久我就投降了，我直接告訴他我不知道。原因很簡單，因為我沒用過，而沒用過最近也不會用到的東西，我大概不太會去碰。因為『吾生也有涯，而知也無涯。以有涯隨無涯，殆已。』數千年前，莊子就知道這件事了，我又何必勉強呢? 得知道，所有的技術都是為了應用，學技術本身當然是愉快的，如果學技術本身就可以賺錢，那何樂而不為?然而非也，技術能用到對的地方，才能賺錢。不是說賺錢很重要，而是玩物喪志恐怕也不是成年人可以一直走的路，也因此，誠實的面對自己的知與不知，選擇在有限的時間內，將有需要的技術盡快地掌握，是我這幾年來學習的原則。 捷徑只有一條 我曾經聽一位老師說過，在專案管理當中，只有一個方法能立即加快速度，那就是減少浪費。加人、進修、提升能力、凝聚向心力…都很可能治標不只本，再說一次， 只有一條路可以真正的加速，那就是減少浪費 。其實，學習也是。請原諒我這麼說，但這年頭很多的大學，四年的時間基本上是浪費了，你常常看到為何有些年輕人不需要念大學就可以有所成就，因為，雖然學習是重要的，但依照別人排好的時間表以及重點來學習，它不是為你量身訂做的，對學習者來說當然弊多於利。要知道，現行台灣的教育制度也不是培養人才的最佳解決方案。但沒辦法，對於一般人來說，恐怕這是唯一的路，所以莘莘學子跟著大家一起念大學，之後跟著大家一起找 不到 工作。如果你不想做『一般人』，就得要想辦法減少浪費，從學習到專案，都是如此。 新舊從來都不是問題 我有一個朋友，其實算是前輩了，他公司還是用Delphi開發系統。幾年前第一次聽到的時候我很是訝異，我不是訝異Delphi還活著，它活著我知道，但在這個技術一個

如果你申請好了新版的Line Messaging API帳號。(申請位置位於 https://business.line.me/zh-hant/services/bot )，就可以建立一個Line對談機器人了，你要讓你的Line機器人能夠透過程式來回覆用戶的訊息，那關鍵當然是底下這個WebHook: 這個WebHook的設定位置可以從Line Messanging的管理介面進入: 一但你設定好WebHook，所有從用戶傳送給LineBot的訊息，就會傳送到這個WebHook，而你透過程式碼寫的這個WebHook，在接收到這個訊息之後，就可以依照用戶的訊息內容，來回應(回覆)不同的訊息給用戶。這就是一個Line對談機器人最基本的架構: 簡單的說就是，你只要寫一個WebHook(C#開發人員可以用WebAPI寫)，放上網站，他就是一個網址，而你的機器人與用戶對談時，Line會把這個訊息封包傳送到你的WebHook這個網址，你可以在接受到訊息封包後進行剖析，取得用戶說的話(或是傳送來的圖片)，透過後端的對談邏輯(可以用以前我們介紹過的LUIS來進行文字的斷字和語意分析)判斷，然後把該回覆的訊息組出來回覆給用戶，大致上是這樣。 所以你不難理解，那個WebHook顯然是我們第一個要實做的東西。其實開發起來很簡單。首先，請先用Visual Studio 2015建立一個Web專案: 在下一個畫面，專案範本請選擇Empty，但記得勾選底下的WebAPI: 完成後的專案框架大概是底下這樣，請在Controllers資料夾底下新增一個Controller: 我們先叫他LineChatController好了: 完成後大概是底下這樣: 接著我們就可以開始寫程式了，但別忘了，在寫程式之前，請先引用LineBotSDK這個Nuget Package: 完成後，請直接將底下這段程式碼填入你的WebAPI Controller， 請留意你要自行替換掉Channel Access Token: 所謂的Channel Access Token基本上就代表著你的Line Messanging，你在程式碼中想要透過你的Bot回覆或發送訊息，都需要這個Channel Access Token，他可以在你的Line Messanging WebHook管理站台上找到(第一次進來是空的，請

新版的Line Messaging API，要主動發送訊息給用戶不是很困難，主要是透過Push API，可以參考底下的官方說明 : https://devdocs.line.me/en/#push-message 另外，如果你想申請一個Line Bot，可參考: 關於LineBot (1) - 用c#建立一個LineBot 前陣子說過，我們為了團隊開發方便，做了一個 Nuget Package 以便於讓撰寫C#的開發人員可以方便的進行Line Messaging API的操作。 所以，如果你想要透過該SDK來發送訊息給用戶，可以透過底下的指令: isRock.LineBot.Utility.PushMessage(               UserId, 要傳送的訊息, AccessToken); 別忘了使用前，要先引用linebotSDK這個套件: 當您在.net 4.x的專案中，安裝上述lintbotSDK，即可透過前面提到的指令發送訊息給用戶，但請注意，該用戶必須加你的bot為好友。 你可能在使用時會碰到一個問題，怎麼知道用戶的id呢? 請注意，PushAPI的Line用戶id並非你的line ID，而是一長串項是底下這樣的id: U6OX388eOX3634X2OX2e341OX06b8OX4123 這個ID會在你的用戶跟你的bot交朋友，或是對談的時候，由系統傳送給你所設定的WebHook網址(其本質上是一個asp.net WebAPI或類似的API服務)。你會在Line傳遞給該WebHook URL的封包中的JSON形式資料內獲得。 也就是說，當你的用戶傳訊息給你的Bot，或是與你的Bot做朋友(或封鎖)，你所在你的LineBot後台，所設定的這個WebHook，都會收到這些相關的訊息。其設定位置如下: 訊息內容是以JSON的格式出現。 但是，如果你還不知道怎麼寫一個WebHook，該怎麼辦呢? 寫個WebHook其實很簡單，以asp.net來說，就是寫一個asp.net WebAPI即可。(有空我再說明，但今天比較沒空) (2017更新，WebHook開發方式請參考 這裡 ) 如果你沒空寫，可以先用底下這個工具(注意這個工具 僅限測試使用 ，我們不保證其穩定性與可用性、與資料安全性): http://isbaas.azurewe