Блог

Каково поведение по умолчанию при нарушении Authorize атрибута в ASP.NET Ядро?

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

}
 

Кажется, что он перенаправляет на /Account/AccessDenied , если у пользователя недостаточно прав и /Account/Login если пользователь еще не вошел в систему.

Я прав?

Я ничего не вижу об этом в документах.

Это зависит от того, какое промежуточное программное обеспечение аутентификации вы используете.

Промежуточное программное обеспечение проверки подлинности на основе файлов cookie по умолчанию перенаправляет пользователя, не прошедшего проверку подлинности, в /Account/Login, а уже прошедшего проверку подлинности пользователя — в /Account/AccessDenied . Это поведение можно отключить, установив флаг AutomaticChallenge в параметрах промежуточного программного обеспечения, после чего он просто вернет ответ HTTP 401, когда пользователь не вошел в систему, или 403, когда пользователь вошел в систему, но не выполняет требования авторизации.

Промежуточное программное обеспечение JWT bearer будет возвращать только коды состояния 401 или 403.

Другие промежуточные программы могут вести себя по-разному, в зависимости от того, какой стандарт они пытаются реализовать.

Я подумал, что было бы полезно следовать коду и понимать, что происходит. Значение по умолчанию AuthenticationHandler просто вернет 401 (не прошедший проверку подлинности) или 403 (запрещено). После этого, в зависимости от конфигурации вашего проекта, в конвейер будут добавлены различные обработчики аутентификации.

• Например, когда вы используете AddIdentity и UseIdentity , вы также вызываете UseCookieAuthentication за кулисами, что, в свою очередь, добавляет CookieAuthenticationMiddleware .
• Обработчик CookieAuthenticationMiddleware по умолчанию будет заменен обработчиком по умолчанию CookieAuthenticationHandler , хотя по умолчанию предыдущий обработчик будет сохранен как предыдущий обработчик. Таким образом, обработчики могут решить не участвовать и позволить предыдущему обработчику обработать результат. (Это важно для понимания того, как AutomaticChallenge работает флаг)
• Перенаправление CookieAuthenticationHandler будет перенаправлено на AccessDeniedPath или LoginPath , которые взяты из параметров. По умолчанию эти пути являются /Account/Login и /Account/AccessDenied , но они могут быть переопределены идентификатором при вызове UseCookieAuthentication . (Переопределяется только LoginPath, но используется то же значение).
• Вы также можете вручную обновить эти пути, например:

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

AutomaticChallenge Флаг, упомянутый @blowdart, по умолчанию устанавливается как true, когда Identity добавляет промежуточное программное обеспечение для авторизации файлов cookie. Если вы установите это значение как false, обработчик файлов cookie не будет участвовать, и будет выполнен предыдущий обработчик, возвращающий 401 или 403. (Поскольку предыдущий обработчик будет по умолчанию использоваться по умолчанию)

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