驗證替使用者建立身分識別,授權則是用來判斷使用者能不能使用某一個功能,ASP.NET Core 提供許多的授權 Role、Claims、Policy 等,老實講 Policy 授權使用上有一點門檻,分享一下我的實際用法,也給需要的人參考
驗證替使用者建立身分識別,授權則是用來判斷使用者能不能使用某一個功能,ASP.NET Core 提供許多的授權 Role、Claims、Policy 等,老實講 Policy 授權使用上有一點門檻,分享一下我的實際用法,也給需要的人參考
ASP.NET Core 提供了許多身分驗證的 Middleware,內建的 AuthenticationMiddleware (app.UseAuthentication) 需要搭配 AuthenticationHandler,這裡我將介紹如何使用自訂的身分驗證跟 AuthenticationMiddleware 的串接,驗證成功後替使用者建立身分識別
在 ASP.NET Core 的整合測試我們可以使用 WebApplicationFactory、TestServer,這我前面幾篇已經提過了需要的可以參考之前的文章 WebApplicationFactory、TestServer。Middleware 用上述的步驟肯定是沒有問題的,但是需要的環境、步驟也比較多,可能還會因為其他 Middleware 順序所帶來的影響,今天我還要分享 ASP.NET Core內建 Mock HttpContext 做法,讓我們可以快速的針對某一個 Middleware 進行單元測試
C# 9 開始就可以不用在主控台程式包含 main 方法(Top-level statements),在 .NET 6,ASP.NET Core 6 也支援了 Top-level statements 專案範本,已經直接套用此功能,我用 WebApplicationFactory 寫整合測試時,碰到一點小問題,以下是解決問題的經過
現在的工作大都是使用微軟內建的 Json 序列化套件 System.Text.Json,為什麼要用可以參考 黑大這一篇,在尋求 Json Compare/Diff 解決方案時大都是看到 Newtonsoft(Json.NET) 的 JsonDiffPatch 做法,經同事分享 System.Text.Json 已經有人實作出來了,知道後立馬套用
以往我都是透過 ValidationContext 來進行模型驗證,在 ASP.NET 的模型綁定,骨子裡面也是使用 ValidationContext,他必須要依賴 Validate Attribute,這次我的需求是要驗證 Dictionary<string, object>,ValidationContext 可能就沒有那麼適合,FluentValidation 是 .NET 生態裡的驗證框架, 這次我打算採用它來實作 Dictionary<string,object> 的驗證。
我使用預設的 System.Text.Json 反序列化時 JsonSerializer.Deserialize<Dictionary<string, object>>(json),得到 JsonElement,再透過 JsonElement.Get 系列的方法才能取得正確的資料,這樣有點繁瑣,為此我找到了解方,自行實作 JsonConverter,緊接著,來看看我怎麼處理的
一旦 Web API 部署並開始使用後,它應該是可靠的,並且不應該因任何原因而中斷。另一方面,隨著需求的變化,我們需要更新 Web API 代碼,但這應該不破壞目前 API 的情況下完成,因此新舊版本的 Web API 都將處於活動狀態,功能也要正常。這時候就要靠 Web API 版本控制,我們靠它用於處理不同版本的Web API。微軟的 Microsoft.AspNetCore.Mvc.Versioning 可以讓我們輕易的完成此項目,但我在整合到 Swagger UI / Swashbuckle.AspNetCore 的時候碰到了一些關卡,所幸順利的解決了,以下是我的實作筆記。
前幾年編寫了 [Swagger] 一些 Swagger 編寫文件的技巧和 Client Code Gen ,不過,已經不適用 ASP.NET Core 6,正好,團隊正在重視 API 文件,正好趁這機會更新 Swashbuckle.AspNetCore 使用
前面幾篇使用 ChangeTracking 來幫我們追蹤物件狀態,但他必須公開狀態讓外部可以修改,為了解決不被外部隨意修改的問題,可以利用深複製回傳一份不同實例的物件,這樣就可以不被外部影響;操作資料庫仍是使用 EF / EF Core,當然這不受限,你可以挑選妳喜歡的控制方式,接著,來看看怎麼實現它吧。