Авторизовать, за исключением некоторых страниц html [duplicate]

Использование атрибутов [Authorize] может помочь предотвратить появление ошибок в вашем приложении. Способ, которым MVC обрабатывает URL-адреса (т. Е. Маршрутизацию их к контроллеру, а не к фактическому файлу), затрудняет фактическую защиту всего через файл web.config.

Подробнее здесь: http: //blogs.msdn.com/b/rickandy/archive/2012/03/23/securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute.aspx

Тег в web.config основан на путях, тогда как MVC работает с действиями и маршрутами контроллера.

Это архитектурное решение, которое не может иметь большого значения, если вы просто хотите запретить пользователям, которые не вошли в систему, но имеет большое значение, когда вы пытаетесь применить авторизацию на основе ролей и случаях, когда вы хотите выполнить специальную обработку типов Unauthorized.

Первый случай рассматривается из ответа BobRock.

Пользователь должен иметь хотя бы одну из следующих ролей для доступа к контроллеру или действию

[Authorize(Roles = "Admin, Super User")]

. Пользователь должен иметь обе эти роли, чтобы иметь доступ к Controller или Action

[Authorize(Roles = "Super User")]
[Authorize(Roles = "Admin")]

Пользователь, который может получить доступ к контроллеру или к действию, - это Betty and Johnny

[Authorize(Users = "Betty, Johnny")]

. В ASP.NET Core вы можете использовать Claims и Policy для авторизации через [Authorize].

options.AddPolicy("ElevatedRights", policy =>
                  policy.RequireRole("Administrator", "PowerUser", "BackupAdministrator"));

[Authorize(Policy = "ElevatedRights")]

Второе очень удобно в больших приложениях, где, возможно, потребуется выполнить авторизацию с различными ограничениями, обработкой и обработкой в ​​соответствии с ситуацией. По этой причине мы можем Extend AuthorizeAttribute и реализовать различные альтернативы авторизации для нашего проекта.

public class CustomAuthorizeAttribute: AuthorizeAttribute  
{  
    public override voidOnAuthorization(AuthorizationContextfilterContext)  
    {  }
}

«Правильно выполненный» способ сделать авторизацию в ASP.NET MVC используя атрибут [Authorize].

Реальная власть приходит с пониманием и поставщиком членства в реализации вместе с поставщиком ролей. Вы можете назначать пользователей в роли и в соответствии с этим ограничением вы можете применять разные роли доступа для разных пользователей к действиям контроллера или самому контроллеру.

 [Authorize(Users = "Betty, Johnny")]
 public ActionResult SpecificUserOnly()
 {
     return View();
 }

или вы можете ограничить группу

[Authorize(Roles = "Admin, Super User")]
public ActionResult AdministratorsOnly()
{
    return View();
}

Одно из преимуществ заключается в том, что вы компилируете доступ в приложение, поэтому его нельзя случайно изменить кем-либо, модифицирующим Web.config.

Это не может быть для вас преимуществом и может быть недостатком. Но для некоторых видов доступа это может быть предпочтительным.

Кроме того, я нахожу, что информация авторизации в Web.config загрязняет его и затрудняет поиск вещей. Таким образом, в некотором смысле это предпочтение, в других нет другого способа сделать это.

Использование атрибута Authorize кажется более удобным и более «MVC». Что касается технических преимуществ, есть некоторые.

Один из сценариев, который приходит мне на ум, - это когда вы используете кэширование вывода в своем приложении. Авторизованный атрибут обрабатывает это хорошо.

Другим может быть расширяемость. Атрибут Authorize является базовым только из фильтра box, но вы можете переопределить его методы и выполнять некоторые предварительные авторизации, такие как ведение журнала и т. Д. Я не уверен, как вы это сделаете с помощью конфигурации.

Он существует, потому что он более удобен в использовании, а также совершенно другая идеология, использующая атрибуты для отметки параметров авторизации, а не для конфигурации xml. Он не должен был бить конфигурацию общего назначения или какие-либо другие рамки авторизации, а просто способ MVC. Я говорю это, потому что кажется, что вы ищете преимущества технических возможностей, которые, вероятно, не ... просто превосходное удобство.

BobRock уже перечисляет преимущества. Чтобы добавить к его ответу, другие сценарии состоят в том, что вы можете применить этот атрибут для всего контроллера, а не только к действиям, также вы можете добавить разные параметры авторизации роли для разных действий в одном контроллере для смешивания и сопоставления.