.NET Walker

ChatGPT 也紅了好一陣子，大部分開發人員應該也知道，如果要把ChatGPT的能力整合到自己的專案當中，可以透過 Open AI 所提供的API(或是微軟提供的Azure OpenAI API)。 我們開發LINE Bot也是，想做一個具有ChatGPT能力的LINE Bot非常簡單。如果你是C#開發人員，甚至可以直接用套件和範本來完成。 你可以先用 .net 6 以上的環境建立 WebAPI專案： md testgptbot cd testgptbot dotnet new webapi 完成後，請一併執行 LineBotSDK和LineWebHook範本的安裝： dotnet add package linebotsdk dotnet new install isRock.Template.LineWebHook dotnet new linewebhook 執行後你會看到底下畫面： 這時開啟專案，會看到這些範本內容，主要是LineBotChatGPTWebHookController 這隻： 這隻是寫好的 LINE Bot 範本，同時支援 OpenAI API 和 微軟的Azure OpenAI API。如果您熟悉LINE Bot的開發，只需要把25行的Channel Access Token換掉，順便把 20 行的 Admin User ID換掉(這是處理發生例外的訊息用的)，這樣主程式就完成了。Channel Access Token和Admin User ID這些資訊你可以從LINE Developers Console( https://developers.line.biz/console )找到： 為了讓這個 LINE Bot 可以支援 OpenAI API，我們把需要一個 OpenAI的API Key，這個Key可以從OpenAI的開發人員後台( API keys - OpenAI API )看到： 有了這些資訊之後，只需要把剛才LineBotChatGPTWebHookController 這隻程式碼中的 117 行調整成 return ChatGPT.CallOpenAIChatAPI(…)，並填入剛才取得的key: 將其運行起來之後，你就可以跟這隻 LINE Bot互動了： 你會發現，有了 Ch

吃飽飯，在櫃台結帳，同行的夥伴先走到餐廳門口，突然『啊』的大叫了一聲。 『怎麼了嗎? 』我問。 『下大雨耶』 對方回答。 真的，超級大。 這幾天陰晴不定，原本看起來好好的，突然間大雨傾盆。沒轍，只好站在店家門口等雨停。 突然發現，好像很久沒有好好看看這個城市。 平時乘坐交通工具。 街道對我來說，只是從甲地到乙地的過程，而我對街道而言，估計也只是個過客。 大雨，打亂了這個日常。 不是沒有想過放慢腳步，但總有事情可以塞滿原本刻意留白的行事曆。該學的東西還很多，要處理的事情總是好雜，等著研究的技術問題好難，正在協調的議題比預期的棘手…等忙到告一個段落，也精疲力竭了… 如今 AI 時代，有人說：『 Run, Don’t Walk.』 放慢，是一個奢侈的念頭。 但不知為何，這雨中的街景好像比我記憶中的還美。 有時，雨來的突然。 但若不是大雨阻饒了去路，怎會有時間為街景駐足。 或許，慢下腳步，也不是壞事​🥂 我轉頭對朋友說：『不如，我們再喝杯咖啡☕如何?』 若始終不肯停下腳步，走到哪兒都是過客。 當開始願意為了什麼而停留，身在何處都有了歸屬。

在Web應用程式開發的過程中，我們常常會聽到所謂的 Claim-Based Authentication或Authorization之類似的用詞，中文常直白的翻成『基於聲明的驗證或授權』。 翻譯沒錯，但『基於聲明的…』中的這個『聲明(Claim)』，有點不好理解。 簡單的說，你可以暫時先把所謂的『聲明(Claim)』理解成一張駕駛執照(或身分證)，由監理單位(或戶政單位)發出，發出Claim的單位我們叫 Issuer。 在傳統的 asp.net core web應用程式當中，身分驗證與授權(authentication and authorization)，預設常常都是走 Claim-Based 來實踐的。其實應該說，當我們進入了WEB 2.0時代之後，網站開始需要與用戶端互動，伺服器端需要識別用戶是誰，並針對不同的用戶給予不同的權限，這時，基於聲明的Claim-Based Identity就逐漸成為主流。 在解釋之前，先簡單提一下驗證(authentication)和授權(authorization)，一般來說，『驗證』是確定你是誰(who)，而『授權』則是確定你能做(或能看、能存取)什麼(What)。 為了實現這件事情，一般的網站在開發時，大致會這麼做： 用戶在使用某個網站時，會先透過瀏覽器以匿名方式進到一個登入頁面。進入該頁面後，會先以帳號密碼(或是其他機制、例如email、SMS)進行登入(Login)工作，這就是驗證。通過驗證之後，網頁系統一般會建立一個由伺服器端發出的Claim，這個Claim就像我們剛才說的駕駛執照一樣，可能描述(聲明)著用戶的個人資訊，以及該用戶可以駕駛的車種(也就是權限之類的訊息)。為了確保安全，一般來說，Claim常會被編碼或加密，然後包裹成為一個Token，甚至加入一些檢核機制，以便於能夠確保該Claim(Token)的合法性(例如足以識別該Token是由誰Issue的)。接著，應用程式就可以拿著這個Token(或實作成cookie)，作為憑證來存取特定的資源。 以上這樣的機制，就是Claim-Based Identity。 你可能會覺得疑惑，那我們在開發 asp.net core 網站的時候，有這麼複雜嗎? 感覺好像沒有做那麼多步驟啊!? 其實有，只是 .net 框架主動為你做了大半，所以開發人員常常不知

過去開發 LINE Bot 的時候，我們必須建立一個 WebAPI，把該 WebAPI 作為 WebHook 在 LINE Developer 的後台進行設定，而這個設定需要的是一個可以在 internet 上公開的URL，這樣LINE 的後台才能夠在收到用戶傳來的訊息的時候，把該訊息傳遞給你開發的 WebHook 。簡單的說就是，你的WebHook必須是對外公開的。 但麻煩的是，一般在開發測試階段，我們習慣透過 Visual Studio 或是 Visual Studio Code 進行偵錯測試，然而我們偵錯時候開發工具所給我們的網址通常都是類似 https://localhost:5000 這樣的URL，而這樣的URL 是無法公開在internet上的，因為 localhost 指向的位置是本機(127.0.0.1)，這導致我們無法將其直接設定為 WebHook。 這時，我們可以透過一些工具，幫助我們把測試階段的 localhost 網址，對外公開到網際網路上，具體實現的方式是，在開發人員的機器上，執行一個代理程式，透過這個代理程式搭配外部的伺服器，為我們開發中的 localhost 網址，建立一個 mapping 的外部網址。凡是對這個外部網址進行的HTTP存取行為，就會被轉傳遞到我們 localhost 的開發機器上，如此一來，我們就可以針對開發中的WebAPI進行偵錯測試。 而 DevTunnel ，這個微軟前陣子釋出的工具，就可以幫我們實現這樣的需求。 要安裝該工具很簡單，windows環境可以透過命令列(powershell)安裝: winget install Microsoft.devtunnel 安裝完成之後，請先透過底下網址登入: devtunnel user login 在命令列執行上面這個指令會開啟瀏覽器，請用你的 MS Account 或 GitHub 帳號登入。登入完成後，你就可以透過底下這樣的指令，把 localhost 特定的 port 公開到網際網路上(例如底下的port是5000): devtunnel host -p 5000 --allow-anonymous 執行後，你會看到該工具幫我們建立(取得)了一個mapping網址: 當你第一次點選該網址，會看到底下畫面，請直接點選Continue: