發表文章

目前顯示的是 2020的文章

WebApp如何安全的存放機密資訊

圖片
WebApp如何安全的存放機密資訊 每一個重要的應用程式裡面都有機密資訊,從資料庫的連線字串,到後台admin的帳號密碼,這些大大小小的機密資訊,常常被開發人員存放在source code的某處…咦? 等等… 對,你應該有所警覺,這些資訊怎麼能存放在程式碼裡呢? 這顯然不夠安全啊。但…直到上周,我在上課的時候,還有學員依舊把連線字串和帳密寫死在程式碼中😮。 那你說,好吧,不寫在程式碼『裡面』,那我獨立寫在一個檔案裡面好了,在 .net 的世界裡,這就是 web.config或是 appsettings.json,但…這樣就安全了嗎? 只能說,『相對』安全了點,但還是不夠安全。 關鍵在於,誰能(或誰該)經手這些機密資訊? 早期的概念是把開發和維運團隊切開,讓開發人員無法得知最終的帳密,讓維運的人無法得知程式碼的內容,這樣,除非這兩個人同時被綁架(或彼此串通),不然企業的機密資訊還是可以得到保障。有點像是出納和會計不能是同一個人的道理。 這種保護是,不讓『某一個人』知道所有的資訊。只能說相對安全,並非絕對安全,因為經手機密資訊的人還是太多了。安全的定義是, 不該知道的人,就不要知道。 因此,更好的方式是,讓機密資訊只有單一一個安全存放點,且由單一的某一個人寫入。並且,在取用的過程中維持『不落地』。所謂的不落地,就是不儲存在任何地方。簡單的說,就是需要使用時(例如建立資料庫連線),從安全的存放點取出(帳密),然後就保存在記憶體中,永遠不寫入任何的檔案、資料庫、硬碟…等儲存體。 真能夠實現這件事情嗎? 可以的。 微軟在Azure雲端上,有一個專門提供存放機密資料的儲存庫,稱為Key Vault(金鑰儲存庫),管理人員可以把機密資訊(例如admin的帳號密碼、資料庫的連線帳密…etc.),存放在這個Key Vault中,然後在WebApp的原始程式碼(檔案)中,就不要再存放這些資訊了。當WebApp需要使用的時候,直接問Key Vault拿就可以了: 這樣還有一個莫大的好處,管理人員可以隨時rotate(滾動轉換)帳密資訊,無須開發或維運人員經手。 由於Key Vault是被重重大鎖給保障的(採用高安全性的加密機制),因此可以說是固若金湯,安全無庸置疑…等…等等,不對啊,那我們的WebApp在存取KeyVaul

使用IoC與DI有何意義? (三) 在 Console 程式中使用DI

圖片
這一篇的重點在介紹,如何在Console App中使用DI,但我們的重點卻不是 Console,而是 “使用DI”。 看完 前面 兩篇,你應該要想到一個問題,如果PageModel或MVC的Controller,被呼叫的時候,.net core的DI服務會自動幫我們把Startup.cs中指定好的類別實作,自動注入PageModel(或Controller),那Console中的Main()也會嗎? 好比說,如果我把程式寫成底下這樣: 我在Main()中能夠讀到 _SalaryFormula 的值嗎? 猜猜看? … … … 答案是===> 不會。 原因很簡單,因為Console App的進入點是靜態的 Main()函式,它根本就是一切的源頭,是應用程式被Launch起來的時候,最最最開始的入口,根本 不會有人去幫你 run 上面 5-8行的建構子,所以理所當然的也沒有注入這回事。 那…為何 PageModel可以? 為何MVC的Controller可以? 原因也不難,因為當用戶點選(或連結到)某一個頁面(或某一個Routing)的時候,該頁面(PageModel或Controller)所觸發的那隻程式(Onget() 或 Action),根本就不是整個程式的進入點。它(頁面)是"被"人家執行的。這個執行者不是用戶,是由 asp.net 的框架本身host的。 其實,整個 .net 應用程式的入口一直都是 Program.cs。 請看底下這個MVC Web應用程式的Program.cs: 事實上,Program.cs才是一切程式的進入點,而上面的Host,則是幫我們運行(Launch)起 asp,net web應用程式的背後推手。(未來有空我們再談這個類別) 一直以來,是有一個host幫我們承載每一個頁面的。當asp.net的某個頁面被呼叫,每一個controller被觸發,都不是該class被用戶主動觸發,而是『被』呼叫,被誰呼叫呢? 就是框架本身。正確的流程應該是,某個頁面(或說網址)被呼叫到時,asp.net框架中的底層(middleware, routing…etc.)得知該request,接收該http request的各種參數之後,幫我們new出我們所寫的程式碼(類別),然後把相關參數(像是Que

使用IoC與DI有何意義? (二) asp.net core中的DI服務

圖片
看過了 前面 的介紹,在瞭解了DI的背景需求與前提,以及採用介面來降低對特定物件實作的相依性之後,我們接著來看,怎麼使用asp.net core中的DI服務進行功能抽換。 事實上,早在約莫十年前,坊間就有很多DI框架或套件,例如我之前上課介紹過的Unity Application Block,他是一組DI Container(容器)套件,可以幫助我們更輕易地實現動態注入。而asp.net core則是把DI設計為服務,讓我們在程式碼當中,也可以輕易享有相關的功能。 在軟體開發的領域當中,你慢慢會發現到,真正困擾你的不是寫(新)程式,而是改(舊)程式。在我們開發系統的過程當中,我們會希望盡可能維持原始程式碼的不改變,就能夠加入新功能。原因很簡單,拿 先前 提過的例子,你只是想要修改薪資計算公式,而不是換掉整套HR系統,然後你剛才接手這個系統不久,這時候你不會想看完這套HR系統的整套原始程式碼,才能增加一個小小的薪資計算公式。 另外,你很有可能碰到運氣更差的狀況,就是你手邊根本沒有原始程式碼。 你不過就只是想改一下薪資計算的公式啊?(因為政府剛調整了最低薪資…) 記得Martin Fowler在 重構 一書中說過這麼一段話: 你回頭想,果真是如此,如果程式碼寫得夠好,你根本不需要看完所有程式碼,甚至也無須擁有整套程式碼,就能夠依照需求在系統中添加新功能。 所幸, 前面 我們已經為動態注入奠定好了基礎,請看底下這個Razor Page頁面: (我們之所以從 前面 的Console App改用Razor Page,是為了要展示asp.net core中的DI之故,請務必看過 前面這篇 才能理解底下情境) 上面這個頁面是 .net core 的 Razor Page Model,如果你不熟這個架構,只會MVC,那你就暫時把它當作某個Controller來看好了,後面我們會介紹Console和MVC模式下的DI。 它的執行結果如下: 頁面被載入的時候,會運行到OnGet()方法,其中的程式碼計算出的薪資是 28800,問題來了,OnGet(…)程式碼當中沒有看到誰去new了那個計算薪資的 _SalaryFormula 類別啊? 那這個實行個體是哪裡來的? 莫非是從建構子(上面程式碼第4行)傳入的? 是的,你猜對了。 整個asp.net core框架都支援套DI服務,不管是Web

雲端好物 - 用 Azure Files 建立隨處可存取的 D 槽...

圖片
雲端好物 - 用 Azure Files 建立隨處可存取的 D 槽... USB隨身碟不夠大? 擔心檔案遺失? 想要有便宜好用的儲存空間? 不如把檔案放上雲端吧。想把檔案放到雲端最簡單的方法,大概莫過於 Azure Files了。 當你設定好 Azure Files之後,等同於有一個雲端的隨身碟,不管在任何地方,只要你想要存取檔案,都可以透過安全的連線方式,取得位於雲端大儲存空間的檔案。 設定的方式很簡單,只要你建立好一個 Azure Storage Account,然後找到 檔案共用: 接著,依照下圖的方式,建立一個檔案共用: 建立完成後,選擇連接: 接著會出現底下畫面: 你會看到各種平台連結此雲端硬碟的方式,我們可以選擇某一個磁碟機號,例如上圖選擇W,選擇好後,複製上面這串script,到Windows的PowerShell環境執行: 最後會出現底下畫面: 當啷,一個W槽就出現了。 你可以使用這個 W 槽如同一般的資料夾一樣,所有的檔案也都能在雲端看到: 所有放上去的資料,由於Azure Storage本身就有備份與備援機制,檔案遺失的可能性幾乎等於0,你還可以隨時建立快照集(上圖A),輕而易舉的就讓檔案存取既安全又方便,從此之後檔案隨手可得。 備註:當然,這一切…網路速度要夠快才可以。

使用IoC與DI(Dependency Injection)有何意義? (一) 它到底是甚麼?

圖片
其實我們在好幾年前,就已經談過DI(Dependency Injection)這個主題。當時這類議題被視為進階的開發概念,但如果你最近開始使用 .net core,大概已經發現DI如今已變成.net core中的基本要求。 事實上,從事教育訓練這麼多年的觀察下來,不難發現其實還是有相當多的開發人員不真的很明白,到底DI對於軟體開發有何意義? 它能帶來什麼價值? 這一篇希望能夠用一個較為具體的實例,對初學者解釋到底什麼是DI,以及它能帶來的效益。 結論 先說結論,對開發人員來說,使用DI能夠帶來 提高 可測試性(testability) 以及 提高 可擴充性 的價值,同時降低相依性,讓程式碼便於維護。 在 asp.net core當中DI如今已是基本方案,asp.net core 是以 服務(DI Services) 的形式把DI這個機制實現在框架當中。讓開發人員不管是用 razor page, MVC, 或是其他開發方式,都可以(幾乎是必須)採用DI服務。 我們很久以前就說過,『框架』本身其實就是一種限制、一種引導,誘導開發人員往某一種方向去開發程式。而如今 asp.net core 把DI納作框架的一部分,就是在引導開發人員在開發時走向某一個路線。 什麼路線呢? 就是高可測試性、低耦合以及高可擴充性,如果兩相比較,我覺得asp.net core中的DI可以為開發人員實現高可測試性這個目的的可能性大概會更高一些,估計是因為最近幾年,unit test已經成為開發領域的某種潮流。 什麼是物件相依性 但不管如何,.net core已經把DI視為基礎,而你要理解這一切,得先搞清楚什麼是物件的相依性。 我常在上架構設計課程時說,職責分離這個設計概念很容易理解,誰都知道不同職責的模塊或物件就該分離,問題是怎麼決定誰的職責是甚麼? 到底誰又該跟誰分離? 等到有一天你真的開始設計,就會發現理解是一回事,真的明白到能夠動手設計又是另一回事… 看個例子,我們先來了解一下背景需求。 假設,我們打算為企業建構一個薪資計算的功能,已知薪資計算會依據三個參數,分別是本月上班時數(WorkHours),時薪(HourlyWage),以及請假時數(PrivateDayOffHours)。 也就是說,倘若Eric本月上班 19天,每天8小時,時薪200,本月請假1天,每請假一天倒扣200元,則E

千呼萬喚始出來:動態修改LINE Bot WebHook 的 API

圖片
很多人期待這組API很久了,終於,在光輝的十月,LINE通知大家,這組API出現了😍: https://developers.line.biz/en/news/2020/10/06/messaging-api-update-october-2020/ 過去,開發者要動態修改LINE Bot的WebHook是不可能的。😢 唯一的方式是去LINE的Developer後台 手動 修改。 但這造成了許多LINE Bot開發廠商的維運難度。 想像一下,你需要為近百個客戶同時升級改版,更新WebHook的時候,會是一個多大的工程? 😒 還不僅如此,有許多LINE Bot應用廠商,自己也做了LINE Bot的管理後台,想讓客戶輸入LINE Bot的Channel Access Token,就可以幫客戶的LINE Bot動態賦予不同的行為。但過去,這也無法達成,非得要到客戶的後台去設定不可。(但直接去客戶後台修改? 還是手動? 有點 low 了吧…) 而現在這一組API,則徹底的解決了這個問題。現在,你只要有LINE Bot的Channel Access Token,就可以動態幫LINE Bot隨時設定或調整WebHook URL。 LINE公布了這組API之後,我們的SDK當然立刻更新。 現在,你只需要透過底下這樣的指令,就可以動態設定 LINE Bot的WebHook: isRock . LineBot . Utility . SetWebhookEndpointURL ( ChannelAccessToken , WebHookUrl ) ; 想要抓取當前LINE Bot的WebHook也不是難事: var ret = isRock . LineBot . Utility . GetWebhookEndpointInformation ( ChannelAccessToken ) ; 上面取得的ret,會有底下2個屬性: active屬性可以得知當前是否有使用WebHook,而endpoint當然就是WebHook的url囉。 想要測試 WebHook是否正確也可以用 API呢,例如: ret2 = isRock . LineBot . Utility . TestWebhookEndpoint ( Chan

導入敏捷最難的是什麼?

圖片
『導入敏捷最難的是什麼?』上課時同學這麼問。 『這問題,我可是很有經驗呢。』我心裡這麼想著,然後慢慢的回答… 導入敏捷最難的是…『組織總想在其他條件都不改變的狀況下,實現敏捷轉型。』 我常說:『人人擁抱敏捷,但真實狀況是…沒人想要改變。』 你說,不會啊,我們公司常常改變! 老闆總是朝令夕改…搞的大家無所適從。 我笑著說:『是啊,那是他改變你,不是改變他自己。況且,你不是也不喜歡別人常常改你的工作模式…對吧?』 總之組織從上到下,沒人喜歡『被改變』。 所以,導入敏捷當然可以…但,不能碰KPI、不能違反ISO、不能調整考績與獎金制度、不能改變合約簽訂方式、不能變更HR既定規則、不能調整休假與簽核流程、不能違反愚蠢的勞基法規法條、不能取消既有的公司會議(不管多麼無效)、不能改變組織結構、不能拆分部門與團隊…在所有外界環境都不改變的狀況下,要我們協助導入敏捷…幹的好。 這不是『難』,這根本是『為難』。 但我得說,這才是企業轉型的真實狀況。有興趣『談』轉型的老闆很多,有膽量豁出去的可算是鳳毛麟角,除非… 『除非什麼?』學生問。 除非…那公司差不多快掛了,死馬當活馬醫,這時候老闆可能會破釜沉舟,孤注一擲。但也往往能帶來最好的成效。 這也是大家常常看到,新創和小公司比較容易導入敏捷的關係。在大概超過百人左右的組織中,即便想要在一個小部門中導入敏捷,都很容易碰到與企業規範衝突的問題。 要知道,你可是在跟整個組織既有的習慣和文化對著幹,後台不夠硬,身段不夠軟,導入到最後,往往沒能改變組織,先陣亡的會是你自己。 『那怎麼辦?』另一位學員問。 『看起來很難,但也不是沒辦法。』我說『先準備好自己,別聽到台上講的精彩,一股熱血就勇往直前。也別亂找顧問,敏捷轉型不是小事。要幫企業實踐轉型,得長時間陪著企業一步步解決問題,身為顧問,你要非常清楚每一個工具、每一個activity想達成的目的,然後幫助企業選擇最適合的方式,量身訂做,趨吉避凶。』 好啦,先上課吧。先搞懂Scrum每一個角色和活動的意義,到時…才能真的幫上企業實現轉型。

什麼是Azure Cosmos DB?

圖片
Cosmos DB是微軟的高可用性、低延遲資料庫。近代的電商網站或微服務應用程式,都強調所謂的高可用性(就是網站或服務很難死掉)與快速回應,一旦系統上線,大概都不太容許服務的中止或延遲。 要實現這個能力,我們在Web或AP層可以做HA(high availability)架構,一般透過負載平衡(Load Balance)搭配Auto Scale的方式來實現。從Azure的Web App到常見的Container解決方案(像是K8S, AKS)的使用,背後很多的考量都是為了實現這樣的高可用性需求,讓流量增加的時候動態的在Web或AP層自動延展(動態增加伺服器): 但你慢慢會發現,當Web/AP伺服器可以近乎無限的延展之後,瓶頸接著發生在DB身上,因為傳統的關聯式資料庫,要實現像是Web Server或AP Server這樣快速延展分流成本相對而言非常高。且在資料的抄寫和回應的速度上要能夠有所保障,其架構都不若Web/AP Server的Scale那麼單純。 過去,用戶端的數量大多可以預測,但現在人手一台平板手機加NB,網際網路上的服務所面對的用戶端數量較之以往不可同日而語,如果要支撐一個全球服務的網站,傳統DB的Cluster架構常常力有未逮。 舉例來說,我們知道在資料處理上,有個CQRS架構(讀者可以上網搜尋相關資訊,例如 https://docs.microsoft.com/zh-tw/azure/architecture/patterns/cqrs ),其基本的概念是,真實世界中,資料查詢(讀取)與寫入的比例其實並非對等的。例如,台灣前陣子的口罩銷售地圖這類的應用,很明顯查詢的需求遠高於更新(寫入),大部分的全球化應用都有類似的情境。而傳統的資料庫程式設計,卻往往將讀取和寫入設計成同樣的工作通道(例如同樣的db access connection)。 倘若我們可以將資料的讀取,分散在全球不同的資料中心,讓讀取的節點可以分散,而工作比例較低的寫入動作,僅在其中一兩個節點進行,再將寫入的資料自動抄寫到不同的讀取節點,將有助於提升應用程式的查詢效能,這對於很多全球化或分散式的應用來說,是一個相對理想的架構。 這時候,NO SQL(Not Only SQL )類型的資料庫,就開始被許多大型網站考慮了,而Cosmos DB就是一個可以滿足這樣需求的資料庫。

Azure DevOps in Action - 在Build Pipeline當中加入自動化程式碼檢查

圖片
在CI Pipeline當中,想要持續提升開發品質,除了單元測試,靜態程式碼檢查也很重要。在Build Pipeline運行過程中,適度的加上程式碼檢查工具,可以幫助我們掃描程式碼的狀況,檢查是否有具有潛在風險的程式碼。 我們常聽到的程式碼壞味道(code bad smells),或是技術債(technical debt),都是靜態程式碼檢查的主要標的。 技術債這個概念是1992年,由Ward Cunningham首次提出。而後常出現於Martin Fowler等大師的文章中。泛指為了縮短開發時程,而在開發過程中做出的妥協(像是安全性、測試、變數的命名…等)雖然可以得到立即的效果,但未來將可能連本帶利付上更大代價。 而SonarCloud,就是這類掃描工具中的翹楚,他是一個獨立的第三方產品,但可以跟Azure DevOps Pipeline做很好的整合。 要在Build Pipeline當中加入SonarCloud進行程式碼檢查非常容易,你只需要到SonarCloud.io申請帳號,並且在Azure DevOps站台上安裝免費套件後,即可進行這樣的掃描。 整個服務完全免費。 安裝SonarCloud 要使用該服務在Build Pipeline上,首先得安裝套件,請至底下網址: https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarcloud 在出現下列畫面時,選擇 Get it free: 接著在出現的畫面中,選擇你的組織(站台),然後按下Install即可: 安裝完成後,你會發現在建立Pipeline的時候,多了幾個Tempalte: 上面這幾個『…With SonarCloud』的Build Process Tempalte,就是安裝套件後,自動幫您加上的。針對 .Net Core和傳統 .Net Framework環境的開發專案,都有著適合的建置範本可供參考。 申請帳號 在使用之前,我會建議你,先到 https://sonarcloud.io/ 這個站台建立帳號,你只需要透過Azure DevOps帳號(也就是MS Account)即可以Single-Sign-On的方式,取得SonarCloud帳號: 進入SonarCloud的P