用ASP.NET Core 2.1 建立规范的 REST API -- 保护API和其它
預備知識:?
?用ASP.NET Core 2.0 建立規范的 REST API -- 預備知識?
?用ASP.NET Core 2.0 建立規范的 REST API -- 預備知識 (2) + 準備項目
建立成熟度2級的 API請看這里：
用ASP.NET Core 2.0 建立規范的 REST API -- GET 和 POST,?用ASP.NET Core 2.0 建立規范的 REST API -- DELETE, UPDATE, PATCH 和 Log和用ASP.NET Core 2.1 建立規范的 REST API -- 翻頁/排序/過濾等
HATEOAS：用ASP.NET Core 2.1 建立規范的 REST API -- HATEOAS
緩存和并發：用ASP.NET Core 2.1 建立規范的 REST API -- 緩存和并發
本文所需項目代碼(右鍵另存, 后綴改為zip):?https://images2018.cnblogs.com/blog/986268/201806/986268-20180612151833673-1851218969.jpg
認證和授權
認證/身份驗證 Authentication, 是驗證想要訪問特定資源的人/系統的身份的過程.
授權 Authorization, 是確認已認證的用戶擁有足夠的權限去做某些事的過程.
打個比喻: 認證是一個人可以進入到房間的權限, 而授權則表明這個人可以在房間內做哪些事.
?
認證的過程可以和應用程序分開并且還可以被其它的服務使用, 但是授權的過程通常是針對某個應用程序, 不同的角色會擁有不同的權限.
?
HTTP協議提供了一個協商訪問被保護資源的機制, 下圖就是HTTP認證:
標準的認證流程開始于一個訪問服務器被保護資源的匿名請求, HTTP服務器隨后處理了該請求并決定拒絕讓它訪問被保護的資源, 因為該請求沒有憑據; 隨后HTTP Server發送了一個WWW-Authenticate Header回去, 這表示它需要這套認證方案. 然后客戶端再次發送請求的時候包含了一個Authorization Header, 它的值符合HTTP Server的認證方案. 當服務器收到這次請求時, 它驗證了Authorization Header里的憑據, 并讓請求通過了管道.
服務器可以提供多種認證方案, 客戶端只需選擇其中一種即可, 上圖中使用的是Basic 認證方案.?還有其它的認證方案:
匿名 Anonymous?也可以當作是一種方案吧, 就當作是授權給所有人好了
Basic 認證方案, 它是一種比較老的方案, n年前經常被使用. 它太簡單了, 它的值是含有用戶名和密碼組成的字符串, 并用冒號(:)連接, 并且編碼為Base64字符串. 例如username為dave, 密碼為1234, 那么Authorization Header的值就是:?Authorization: Basic?ZGF2ZToxMjM0.
Digest 認證方案, 它作為Basic的代替者出現的. 服務器會給客戶端發送一個隨機字符串作為一個challenge(盤問, 質疑, 挑戰), 這個隨機字符串叫做nonce(可以理解為臨時生成的字符串). 而客戶端通過發送一個帶有用戶名, 密碼, nonce和其它信息的hash來進行認證.
Bear 認證方案, 它是最流行也是更安全的認證方案. 它使用Bearer Tokens (承載令牌) 來訪問由OAuth 2.0協議保護的資源. 任何擁有bearer token的人都可以訪問相關的資源. bearer token的生命周期通常很短, 會過期. 例子: Authorization: Bearer:?eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c.
NTLM認證方案, 它是NTLAN Manager的縮寫, 它是一種挑戰--響應的方案, 要比Digest更安全. 這種方案使用Windows憑據來轉化盤問的數據, 而不是使用編碼的憑據.
Negotiate 認證方案, 它會自動選擇NTLM方案和Kerberos協議中的一個, Kerboros協議比NTLM快.
后兩種方案都僅限于Windows系統.
這幾種方案里Basic提供的保護程度/級別最低, 而Negotiate最高/強.
ASP.NET Core可選擇的認證提供商就很多了, 例如ASP.NET Core Identity. 但是它主要用于包含頁面的web應用, 例如MVC或Razor Page, 并不適用于REST/Web API, 所以不介紹它了.
如果應用部署在云上, 可以使用Azure Active Directory(AAD)?和?Azure Active Directory B2C (Azure AD B2C). 我沒用過, 就不介紹了.
第三方的認證提供商有很多: AspNet.Security.OpenIdConnect.Server(ASOS),?IdentityServer4, OpenIddict, Pwdless.....
我一直在用Identity Server 4, 但是這里不會深入介紹, 這里主要介紹如何實現REST API, 如果有需要的話, 可以寫一系列關于Identity Server 4的文章.
?
選項很多, 但是要實現的話還需要了解JSON Web Tokens (JWT), 它是一個基于JSON的開放工業標準, 它用于為雙方表示一些聲明. 它提供了一種緊湊的, 自包含的方式在雙方之間用JSON對象來傳輸信息.
JWT使用?HMAC secret?或?RAS公有和私有鍵對(key pair)?這兩種方式來進行簽名.
JWT由三部分組成:?header,?payload,?signature. 形式如下面的偽代碼:?[X=base64(header)].[Y=base64(payload)].[signature([X].[Y])]?.
去這個網址可以更直觀的理解這三部分:?jwt.io
JWT token最終是一個字符串, 它的三個部分用點(.)分開, 前兩部分(header payload)是Base64編碼的字符串; 最后一部分是前兩個Base64字符串的組合, 也是用點(.)分開并進行了簽名, 如下圖:
?
?使用Bearer方案和JWT的流程如下:
?
配置項目,?在Startup的ConfigureServices里:
如果使用Identity Server 4的話, 這里就可以不這樣寫了.
首先我們配置使用Bearer認證方案, 然后通過AddJwtBearer設定一些參數. Configuration里面的值可以放在appSettings.json里面或者其它地方:
然后在Configure方法里調用app.UseAuthentication()方法, 要在app.UseMvc()之前調用:
最后使用[Authorize]屬性標簽把CountryController保護起來, 也可以應用于Action級:
發送不帶Authorization Header的請求來測試:
返回 401 Unauthorized 未授權.
返回的Header里面告訴我們應該使用Bearer認證方案.
?
下面我們需要一個可以生成JWT token的節點, 針對本文我就在本項目里建立這個節點吧:
請求token的地址是 /api/authentication, 請求token用的是Basic方案, Post方法里就是先解碼, 驗證用戶名和密碼, 成功后調用GenerateToken生成token.
那就按要求再次發送請求:
注意這里usename:password的base64編碼是:?dXNlcm5hbWU6cGFzc3dvcmQ=
現在我獲得了token, 然后我用token再次請求Country資源:
資源就可以正常的訪問了.
?
想要解析這個token, 需要到jwt.io:
箭頭處需要填上secret.
?
這個例子比較簡單, 實際應用中還是使用Identity Server 4之類的東西吧.
?
使用HTTPS
根據官方文檔(https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-2.1&tabs=visual-studio#require-https), 它建議ASP.NET Core web應用都應該調用HTTPS重定向中間件, 這樣就可以把所有的HTTP請求轉換為HTTPS.
只需要在Startup的Configure方法里調用UseHttpsRedirection()方法即可:
而在ConfigureServices方法里可以配置這個中間件:
?
HSTS (HTTP 嚴格的傳輸安全協議)
web應用通過使用特殊的響應header可以選擇使用加強的安全協議OWASP(Open Web Application Security Project), HSTS(HTTP Strict Transport Security). 當所支持的瀏覽器接收到這個header的時候, 瀏覽器就會阻止任何通過HTTP到指定域名的通信, 會使用HTTPS代替. 同時它也會阻止從瀏覽提的提示框點擊的HTTPS.
為實現這個只需要在Startup的Configure里使用:
?
?一般不建議在開發環境使用Hsts, 因為瀏覽器極有可能會緩存HSTS 的header. 默認情況下,?UseHsts會排除本地回路的地址.
UseHsts會排除下列回路宿主:
localhost?: IPv4 回路地址.
127.0.0.1?: IPv4 回路地址.
[::1]?: IPv6 回路地址.
可以在ConfigureServices方法里對它進行配置:
這部分具體請查看文檔:?https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-2.1&tabs=visual-studio#http-strict-transport-security-protocol-hsts
?
CORS 跨域請求
配置注冊CORS需要在Startup的ConfigureServices方法完成:
針對整個應用啟用CORS需要在Configure方法里調用下面的方法:
應該盡早的調用該方法, 以便在它后邊注冊的節點都可以被跨域訪問.
這是第一種方法, 使用的是lambda表達式.
注意URL地址結尾不要有/, 它會引起錯誤.
這種方法使用的是CorsPolicyBuilder 類, 它擁有Fluent API, 可以串接方法調用:
?
第二種方法是使用策略.
在ConfigureServices里配置好命名的策略:
在Configure方法里使用該策略:
另外也可以不適用UseCors(), 而是在下面這幾種級別指定使用該策略:
Action級別:
Controller級別:
全局Controller級別:
這么用的話, 需要禁用CORS策略就:
?
關于CORS的具體配置, 還是請參考官方文檔:?https://docs.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-2.1
?
Rate Limiting 速率限制
速率限制是指限制被允許的請求到API（或某個特定的資源）。這樣就可以保護API，避免一些非正常使用的場景，例如網絡爬蟲或請求太多而導致API的性能嚴重下降，Dos和DDos。針對這點我們采取的節流策略是控制允許訪問API的請求的頻率/速率，它可以決定特定的請求是否被允許。
例如客戶端只允許每小時有100個請求到達API，也可以按天計算，還可以帶著IP地址一起限制。
響應的Header可以用來表示速率限制，但是這些Header并不是HTTP標準。這些header都以X-Rate-Limit開頭。
X-Rate-Limit-Limit,?這個表示添加了限制并包含了限制的有效期。
X-Rate-Limit-Remaining，表示該客戶還剩下多少個被允許的請求。
X-Rate-Limit-Reset，提供關于何時限制會被重置的時間信息。
如果達到限制了，這些響應會返回429 Too many requests?狀態碼。有可能會包含一個Retry-After 響應Header，而響應的body應該包含解釋當前狀態的細節信息。當然這都是理論上要求的。
?
下面去實現，首先安裝這個庫?AspNetCoreRateLimit?(https://github.com/stefanprodan/AspNetCoreRateLimit)：
首先在Startup的ConfigureServices里面注冊，用到了MemoryCache：
這里配置的是IP限制，它允許有很多規則，這里我只用了一個：針對所有的資源，每5分鐘最多3次請求。
現在，我需要注冊一個策略存儲和速率限制計數器的存儲，這兩個是被中間件使用。所以還需要注冊這兩個服務：
這里都使用的是Singleton單例，因為我們需要的是針對全局的請求來做操作。
接下來要在管道里添加中間件，它應該放在靠前的位置，在日志和異常之后：
?
測試，發送一個請求看結果：
可以看到5分鐘內還剩下兩次請求的配額。限制重置的時間大約在5分鐘之后。
發送請求超限之后，就會返回429：
Retry-After提示了再過294秒后可以再試試。。。
而響應的body是這樣提示的：
?
我們再組合幾個其它的規則：
現在允許5分鐘10次請求，但是每10秒鐘最多只能有兩次請求。
第一次請求后：
5分鐘內還剩9次，然后我10秒內連續發送兩次請求，然后再發送一次請求：
這時超出了限制，Header里：
提示6秒后可以重試, 6秒后再次發送請求：
?
這個庫還是挺靈活強大的，更多功能還需要看官方文檔。
?
API 文檔
業界通常會使用Swagger OpenAPI來對RESTful API進行格式化描述，而Swagger OpenAPI的當前版本是v3.
ASP.NET Core有一個第三方庫Swashbuckle，它支持Swagger，但是只支持版本2，版本2有個重要的缺陷就是不支持Action重載，之前HATEOAS的文章里提到過我們需要使用這種重載。所以Swashbuckle暫時并不是完全合適，所以我就不裝它了。
就暫時不弄自動文檔了。。。
?
單元測試
需要使用到xUnit和Moq，這里不介紹了。
關于xUnit，我寫過幾篇文章，有興趣可以參考下：
http://www.cnblogs.com/cgzl/p/8283610.html
http://www.cnblogs.com/cgzl/p/8287588.html
http://www.cnblogs.com/cgzl/p/8438019.html
http://www.cnblogs.com/cgzl/p/8444423.html?
Moq的文章博客園應該有，如果需要的話，我可以寫一下。
?
其它
其它可能需要了解的包括：POSTMAN/Newman自動化測試，CI，CD，GraphQL等等。我就不介紹了?
這個系列文章就到這了。
源碼（我還需要整理一下源碼，現在有點亂）：https://github.com/solenovex/ASP.NET-Core-2.0-RESTful-API-Tutorial
相關文章：
用ASP.NET Core 2.0 建立規范的 REST API -- 預備知識
用ASP.NET Core 2.0 建立規范的 REST API -- 預備知識 (2) + 準備項目
用ASP.NET Core 2.0 建立規范的 REST API -- GET 和 POST
用ASP.NET Core 2.0 建立規范的 REST API -- DELETE, UPDATE, PATCH 和 Log
用ASP.NET Core 2.1 建立規范的 REST API -- 翻頁/排序/過濾等
用ASP.NET Core 2.1 建立規范的 REST API -- 緩存和并發
原文地址: https://www.cnblogs.com/cgzl/p/9165388.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的用ASP.NET Core 2.1 建立规范的 REST API -- 保护API和其它的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基于 Consul 实现 MagicOn
- 下一篇： VS2017 15.8第二个预览版本提升