违反ASP.NET核心中的Authorize属性的默认行为是什么？
[Authorize(Roles = "Administrator")]
public ActionResult ShutDown()
{
}
如果用户没有足够的权限，它似乎会重定向到/Account/AccessDenied，如果用户还没有登录，它会重定向到/Account/Login。
我是对的吗？
我在文档中没有看到任何相关内容。
答案 0 :(得分：4)
这取决于您正在使用的身份验证中间件。
默认情况下，基于cookie的身份验证中间件会将未经身份验证的用户重定向到/ Account / Login，将已经过身份验证的用户重定向到/ Account / AccessDenied。可以通过在中间件选项中设置AutomaticChallenge标志来关闭此行为，此时它将在用户未登录时返回HTTP 401响应，或者在用户登录时返回403，但不满足授权要求。
JWT承载中间件只返回401或403状态代码。
其他中间件的行为可能会有所不同，具体取决于他们试图实施的标准。
答案 1 :(得分：2)
我认为遵循代码并了解正在发生的事情可能会有所帮助。默认AuthenticationHandler只会返回 401 （未经身份验证）或 403 （禁止）。之后，根据您的项目配置，不同的身份验证处理程序将添加到管道中。
AddIdentity和UseIdentity时，您也会在幕后调用UseCookieAuthentication，然后再添加CookieAuthenticationMiddleware。 CookieAuthenticationMiddleware将使用CookieAuthenticationHandler替换默认处理程序，但默认情况下，前一个处理程序will be kept作为先前处理程序。这样处理程序可能决定不参与并让前一个处理程序处理结果。 （这对了解AutomaticChallenge标志如何工作很重要）CookieAuthenticationHandler将重定向到从选项中获取的AccessDeniedPath或LoginPath。截至default这些路径为/Account/Login和/Account/AccessDenied，但overriden时，身份可为calls UseCookieAuthentication。 （只有LoginPath为overriden，但使用了相同的值。）您也可以手动更新这些路径，例如：
services.AddIdentity<ApplicationUser, IdentityRole>(opts =>
opts.Cookies.ApplicationCookie.LoginPath = new PathString("/Account/my-login"));
Identity添加cookie授权中间件时，默认情况下@blowdart提到的AutomaticChallenge标志设置为true。当你将其设置为false时，cookie处理程序将not participate并且将执行先前的处理程序，返回401或403.（因为先前的处理程序将默认为默认处理程序）
services.AddIdentity<ApplicationUser, IdentityRole>(opts =>
opts.Cookies.ApplicationCookie.AutomaticChallenge = false);