今天，我們將討論如何創建一個僅用于管理身份驗證請求的隔離環境，以及如何有效地將其添加為中間件以保護API。
我們將遵循的一般想法是，首先，我們將創建一個常規服務器，該服務器將具有一個簡單的請求，并且我們需要保護它，因此我們將創建一個中間件來接收標頭并確保我們擁有正確的訪問權限。我們還將使用API_KEY身份驗證來防止內部使用。現在你有了基本的想法，所以讓我們開始吧。
為什么我們需要身份驗證服務器？
您可能想知道為什么我們需要一個身份驗證服務器，難道我們不能只在一臺服務器中處理嗎?顯然，您可以，但是當您的應用程序開始增長時，您可能需要將整體式應用程序轉移到微服務級別，此策略將幫助您解決問題。
設計身份驗證服務器
我們將保持簡單。在我們的身份驗證中，我們不會查看源或網關，而只會查看身份驗證令牌和 API 密鑰。首先，我創建了一個示例 Express App，其中我們剛剛導入了路由，并在存在解析器的情況下使用了默認錯誤處理。
快速應用程序
甚至身份驗證服務器也需要保護，因此我們還將定義一個中間件規則來保護它。對于此示例，我使用的API_KEY但您也可以創建 oAuth 或基本身份驗證。為了使用它，我創建了一個文件，里面有一個中間件，它將檢查API_KEY，如果使用虛擬數據源出現任何問題，則會拋出錯誤。
接口密鑰中間件
在這里，我們使用我們的虛擬數據源檢查API KEYS是否存在且有效，如果情況失敗，則拋出錯誤，否則從路由調用下一個控制器
現在，我們有一個中間件設置，我們實際上可以從API開發開始。我們將僅創建2條路線，但您可以根據需要創建任意數量的路線
登錄
驗證
我已經創建了一個實用程序文件，該文件將創建或驗證令牌，以便我們可以直接使用控制器中的方法。我正在使用軟件包來生成或驗證，但您可以使用您喜歡的軟件包jsonwebtoken
Jwt 實用程序函數
在這里，我們只使用和方法，但理想情況下，您還應該使用方法使您的應用程序為過期的令牌做好準備，然后該過程signverifydecode
從現在開始，我們已經設置了所有內容，讓我們創建路由
路線
在這里，我們導入了所有依賴項，并創建了登錄和驗證的路由。在 login API 中，您可以執行任何與數據庫相關的操作，然后有條件地生成令牌，但在此示例中，我跳過了該部分并直接從 發送令牌。另一方面，為了驗證，我們獲取授權標頭，然后使用方法來驗證令牌是否有效。req.body.payloadverifyToken
如果一切正常，那么在運行服務器和API后，我們將收到以下輸出：
就是這樣，我們的身份驗證服務器已準備好響應。下一步是在任何其他微服務應用程序中使用此服務
使用身份驗證服務
要使用我們剛剛創建的身份驗證服務，我們需要使用 HTTP 請求提供程序。我要使用Axios，但您可以選擇您選擇的任何提供商
我寫了一篇文章，它將幫助我們創建和使外部API調用更加敏捷。以下是本文的鏈接，我建議您也閱讀有關此內容的信息。
如何處理公理和節點J中的不同端點
為 Axios 創建基于類的實例并有效使用它們。
javascript.plainenglish.io
服務生成器
我們將首先創建一個生成器類，該類將處理所有請求的邏輯：api_key
身份驗證服務生成器
在這里，我們創建了一個類，該類將API_KEY作為構造函數參數。此類將創建一個具有標頭和標頭中的 axios 實例，并設置為任何 API 的超時。除了屬性之外，我們還將公開將調用我們為身份驗證服務創建的 API 的方法。baseURL api_key 10000ms login verify
除了生成器之外，我們還將創建一個文件，該文件將創建此類的實例并向我們公開該方法：index.js
實例創建
就是這樣，我們有一個將與auth服務交互的類，并將負責管理更改單例。
創建驗證中間件
現在，我們已經有了服務。下一步是創建一個中間件，為我們處理驗證：
身份驗證服務中間件
在這里，我們創建了一個中間件，它將從req對象中提取標頭并將其傳遞給我們之前創建的方法。verify
創建路由
該過程的最后一步是創建路由并使用中間件。首先，我們需要導入我們創建的中間件，然后在任何測試路線上使用它。通過的情況下，所有未經授權的請求都將被阻止，只有授權的請求才能訪問API。
創建路線
要測試此 API，我們需要傳遞在 API 上獲得的授權令牌，并將其傳入此處。我們不需要通過，因為它對服務級別有限制。loginapi_key
失敗案例場景
如果我們沒有傳遞令牌或傳遞格式錯誤的令牌，則會導致未經授權的請求。
通過案例場景
微服務架構的傳遞案例場景
我們為微服務創建了 2 個服務體系結構，但您可以增加服務以使用身份驗證服務，它將在復制處理程序時完美運行。
京公網安備 11010802030320號