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

Question

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

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

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

Answer 1

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

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

или ограничить в соответствии с группой

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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