ASP.NETコアのAuthorize属性に違反する既定の動作

Question

ASP.NETコアのAuthorize属性に違反する既定の動作は何ですか？

[Authorize(Roles = "Administrator")] 
public ActionResult ShutDown() 
{ 

} 

ユーザーがまだログインしていない場合は、ユーザーが十分な権利と/Account/Loginを持っていない場合、それは/Account/AccessDeniedにリダイレクトようです。

私は正しいですか？

私はドキュメント内に何も表示されません。

Answer 1

使用している認証ミドルウェアによって異なります。

デフォルトでは、Cookieベースの認証ミドルウェアは、認証されていないユーザーを/ Account/Loginにリダイレクトし、既に認証されたユーザーを/ Account/AccessDeniedにリダイレクトします。この動作は、ミドルウェアオプションでAutomaticChallengeフラグを設定することで無効にすることができます。ユーザーがログインしていないときにHTTP 401の応答を返し、ユーザーがログインしているときには403を返します。承認要件

JWTベアラミドルウェアは、401または403ステータスコードのみを返します。

他のミドルウェアは、実装しようとしている標準によって、動作が異なる場合があります。

Answer 2

私はコードを守り、何が起こっているのかを理解することが有用かもしれないと考えました。デフォルトのAuthenticationHandlerは、（認証されていない）または（許可されていません）を返します。その後、プロジェクトの構成によって、異なる認証ハンドラがパイプラインに追加されます。例えば

• 、あなたがAddIdentityとUseIdentityを使用し、あなたはまた、順番にCookieAuthenticationMiddleware追加シーンの背後にあるUseCookieAuthenticationを呼び出します。
• CookieAuthenticationMiddlewareはデフォルトのハンドラをCookieAuthenticationHandlerに置き換えますが、既定では以前のハンドラwill be keptを以前のハンドラとしています。このようにして、ハンドラは参加しないことを決定し、前のハンドラに結果を処理させることができます。 （これは、AutomaticChallengeフラグの仕組みを理解する上で重要です）
• CookieAuthenticationHandlerは、オプションから取られたAccessDeniedPathまたはLoginPathにリダイレクトされます。 defaultによって、これらのパスは/Account/Loginと/Account/AccessDeniedですが、calls UseCookieAuthenticationの場合はIDによってoverridenになります。 （LoginPathのみがoverridenですが、同じ値が使用されます）。

• 手動で、たとえば、同様にそれらのパスを更新できますIdentityはクッキーの認証ミドルウェアを追加したとき@blowdart言及

  services.AddIdentity<ApplicationUser, IdentityRole>(opts => 
       opts.Cookies.ApplicationCookie.LoginPath = new PathString("/Account/my-login")); 
  

AutomaticChallengeフラグはデフォルトでtrueに設定されています。これをfalseに設定すると、Cookieハンドラはnot participateになり、以前のハンドラが実行され、401または403が返されます。**デフォルトのMVCテンプレートはHTTPに、その後以前にログインしたユーザーを返しますログインページに401のリダイレクト応答するように設定されている - これを見つけた（以前のハンドラがdefaulデフォルトいずれかになりますように）

services.AddIdentity<ApplicationUser, IdentityRole>(opts => 
           opts.Cookies.ApplicationCookie.AutomaticChallenge = false);