中年大叔的鹹魚翻身作戰計畫

昨天我們學會了在 ASP.NET Core Web API 發行 JSON Web Token 並且使用 https://jwt.io 網站所提供的測試工具驗證所發行的 JSON Web Token 的內容確實有照我們的意思發行，今天再來學習，當《前端》拿著 JSON Web Token 回來請求任何需要授權要求的 API 服務時，如何驗證該 Token 是否有效。

昨天已經為先前實作的 ASP.NET Core Web API 加入了會員註冊與登入的功能，但是在登入的使用者認證是屬於 Cookie Based Authentication 因為我們所開發的 Web API 主要是要行動裝置使用，參考一些文章的比較，看來 Token Based Authentication 比較合適，所以今天就來學習讓我們的 ASP.NET Core Web API 可以發行 JSON Web Token 吧！

昨天在稍微了解了 ASP.NET Core Identity 會員管理機制之後，已經建立了用來記錄使用者登入以及授權旳資料庫，並將原有的控制器加上了 [Authorize] 授權要求，這樣一來，未經授權的使用者就無法使用我們所開發的 Web API 了。

但是，問題來了，那誰又是合法的授權者呢？要在什麼條件下，才可以使用呢？所以今天的學習目標就訂在《後端》的使用者註冊與登入吧！

上星期五我們在練習完刪除一筆資料前，先出現對話框詢問使用者是否確定要刪除，如果確定就執行 ASP.NET Core Web API 的刪除動作。雖然在前端有防止使用者誤按的防呆機制，但是後端的 ASP.NET Core Web API 卻沒有受到保護，只要有心人士知道 Web API 的 URL 就可以任意地操控我們的資料。

所以今天起先安排一系列與資料保護有關的練習，完成後再往下發展另外的學習。

昨天我們學會了使用 ListView 元件在頁面導覽切換到新頁面之後，讀取資料顯示在頁面上，當時為了方面解說（想控制在 30 分鐘內講完） ，讀取資料的方法是直接寫死在程式碼當中，這不符合在真實的商業應用程式的使用情境（多人使用的系統，資料是有可能隨時變動的，有必要隨時從伺服器端讀取資料）。

因此，今天就來學習如何讀取先前發行到 Azure App Service 的那一支 ASP.NET Core Web API 程式。

昨天已經學會了在 Microsoft Azure 雲端服務平台中建立新的 Web 應用程式服務，以及 SQL Database 服務，今天就來學習如何將 ASP.NET Core Web API（往後要學的 ASP.NET Core MVC 也是相同的發行方式）發行到新建立的 Microsoft Azure 雲端服務平台。

還記得先前練習 Entity Framework Core 時，為了方便講解起見，直接將資料庫的連線字串直接就寫死（Hard Codding）在程式中，如下所示：

public void ConfigureServices(IServiceCollection services)
{
    var connection = @"Server=keigen;Database=DemaeDb;Integrated Security=True;";
    services.AddDbContext<DemaeContext>(options => options.UseSqlServer(connection));    
    ........        
    ........
}

昨天有針對使用 Scaffolding 自動產生的地址的 CRUD 動作方法，配合 RESTful 的說明稍微地了解了一下，今天會再進一步對照程式碼，使用 Postman 實際驗證一下執行的結果。

昨天使用了 Scaffolding 自動產生 Web API 控制器的動作方法，可以對地址（Address）物件做新增、修改、刪除，以及查詢的動作，今天就來一面深入查看這些工具自動產生的程式碼的內容，並實際操作體驗和測試這些，新增、修改、刪除，查詢的功能是否可以正常運作。

昨天興高采烈地試著使用 Scaffolding 自動產生 Web API 控制器的動作方法，但是卻發生了如下圖所示的錯誤：

看來是將 Domain Model 與 DbContext 分開成兩個專案所造成的，解決的方法就是重改架構將這兩個專案合併成一個，否則就是自己動手寫。幾經思量之後決定修改架構，所以今天就來試看看怎麼改。

昨天已經將跟地址有關的基礎資料建立完成，今天就來利用這些資料來建立 Web API 與地址有關的新增、修改、刪除、查詢等功能。