asp.net core 3.x認証-2起動フェーズの構成
6143 ワード
サービスの登録、オプションの設定、認証スキームの追加
スタータープでConfigureServicesはサービスを実行する.AddAuthentication()
以下のサービスを登録します(一部の補助サービスが省略されていることを理解しやすい):
アプリケーション全体の認証には、AuthenticationOptionsというオプションオブジェクトがあります(前の記事で説明しました).これにより、認証を全体的に構成できます.この構成は主に、構成システムがサポートする認証スキームのリストとして表示されます.デフォルトの認証スキーム、デフォルトのログイン時に使用する認証スキームを指定します...デフォルトのログアウト...など.このオブジェクトの応用はaspを用いる.Netcoreのオプションモデルは、AddAuthentication(Action)リロードで構成できます.次のコードを参照してください.
1 services.AddAuthentication(authenticationOptions=> {
2 authenticationOptions.AddScheme("cookie", " cookie");
3 authenticationOptions.AddScheme("jwt"," jwtToken");
4 authenticationOptions.DefaultAuthenticateScheme = "cookie";
5 //...
6 });
このリロードは、上記のコアサービスも先に登録されます.次に、AuthenticationOptionsを初期化する委任を設定し、クラスがAuthenticationOptionsに注入されると、依存注入フレームワークがこの委任を呼び出してこのオプションオブジェクトを初期化します.
もう1つの再ロードAddAuthentication(string defaultScheme)内部も上記の方法を呼び出し、AuthenticationOptionsのみが設定されている.DefaultScheme
AddAuthenticationメソッドは、常にAuthenticationBuilderに戻ります.これにより、チェーンコール方式でAuthenticationOptionsに複数の認証スキームを追加できます.したがって、より一般的な方法は次のとおりです.
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie().AddJwtBearer();
CookieAuthenticationDefaults.AuthenticationSchemeは、どの認証スキームをデフォルトとするかを示すためによく使用されます.その後、クッキーとJwtBearerの2つの認証スキームが追加されました.
AuthenticationOptionsは、アプリケーション全体に対する認証オプションであり、認証スキームの構成時のコンテナとして簡単に理解できます.特定の認証スキームに対しても独自の構成オブジェクトがあります.AddCookie()を例にとると、次のようになります.
1 authenticationOptions.AddScheme(CookieAuthenticationDefaults.AuthenticationScheme, " cookie",);
2 service.Configre(options=>{
4 options.Cookie.Name = CookieAuthenticationDefaults.CookiePrefix + name;
6 options.CookieManager = new ChunkingCookieManager();
7 options.LoginPath = CookieAuthenticationDefaults.LoginPath;
8 options.LogoutPath = CookieAuthenticationDefaults.LogoutPath;
9 options.AccessDeniedPath = CookieAuthenticationDefaults.AccessDeniedPath;
10 }
11 });
CookieAuthenticationOptionsは、このcookie認証スキームに対するオプションオブジェクトであり、将来クラスがこのオプションオブジェクトに注入されると、依存注入フレームワークがこの依頼をコールバックして初期化されます.参照:オプションモデル.もちろんAddCookieには対応するリロードがあり、私たち自身の依頼でこのオプションオブジェクトを初期化することができます.次のようなコードがあります.
1 services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie(" "," ",opt=> {
2 opt.SlidingExpiration = true;// ?
3 // cookie ...
4 }).AddJwtBearer();
今、このコードを見てみると、ずっと親切です.
認証スキーム実行時のコンテナ
AuthenticationSchemeProviderは依存注入容器に一例で登録されているため、登録時に(あまり確定していないと仮定しましょう)AuthenticationSchemeProviderが作成されるはずです.これは、AuthenticationOptionsが登録した認証スキームのリストを含み、AuthenticationSchemeProviderがコンストラクション関数に遍歴していることを示しています.登録されているすべての認証スキームを独自のIDictionary
認証ミドルウェアの挿入
認証プロセスに必要なサービスを登録し、アプリケーションが認証をサポートする必要があるシナリオのリストを構成しただけで、将来のリクエストが到着するときに認証を処理するためにミドルウェアが必要です.コアタスクは、デフォルトの認証プロセッサを見つけ、リクエストから現在のユーザーIDを取得し、httpContextに設定することです.Userプロパティでは、処理の具体的な手順については、次のクッキーベースの認証全体の流れで詳しく説明します.スタータープでConfigreに拡張メソッドで登録するには:
app.UseRouting();app.UseAuthentication();app.UseEndpoints(endpoints =>{ endpoints.MapRazorPages();});
なぜ認証ミドルウェアがappにあるのか.UseRouting();それから、私は本当に理解できません....