Авторизовать атрибут в ASP.NET MVC

Мне сложно понять реальное использование атрибута [Authorize] в ASP.NET MVC. Согласно концепции, если мы украшаем метод контроллера атрибутом [Authorize], доступ к контроллерам разрешен только для аутентифицированных пользователей.

Я разработал приложение ASP.NET MVC без декорирования контроллеров с атрибутом [Authorize]. Я заметил, что если я правильно реализую механизм аутентификации в своем приложении с помощью web.config или каким-либо другим способом, теперь я могу получить доступ к URL {controller}/{action}/{id} конкретного метода действий.

Система всегда запрашивает логин. Это означает, что мои контроллеры защищены. Мой вопрос в том, что, когда я могу защитить свои контроллеры без использования атрибута [Authorize], то в чем его настоящая необходимость?

Ответ 1

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

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

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

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

Ответ 2

Использование атрибутов [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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

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

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

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

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

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

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

[Authorize(Policy = "ElevatedRights")]

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

public class CustomAuthorizeAttribute: AuthorizeAttribute  
{  
    public override void OnAuthorization(AuthorizationContext filterContext)  
    {  }
}

"правильно завершенный" способ авторизации в ASP.NET MVC использует атрибут [Authorize].

Ответ 7

я не знаю, за вклад в ответ на переполнение стека!

Пожалуйста, обязательно ответьте на вопрос. Предоставьте детали и поделитесь своими исследованиями! Но избегайте...

Обращение за помощью, разъяснения или ответы на другие ответы. Делать заявления, основанные на мнении; подкрепите их ссылками или личным опытом.