01 окт. 2013 г., 16:05 отSteveCtechmad

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

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

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

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

Ответы на вопрос(6)

15 мая 2013 г., 16:22 отAlex Vallejo

[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.asp

01 июн. 2012 г., 08:56 отBobRock

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

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

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

[Authorize(Roles = "Admin, Super User")]
public ActionResult AdministratorsOnly()
{
    return View();
}
01 июн. 2012 г., 09:04 отm0s

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

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

01 июн. 2012 г., 13:49 отfrennky

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

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

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

01 июн. 2012 г., 19:36 отErik Funkenbusch

что вы компилируете доступ в приложение, поэтому он не может быть случайно изменен кем-то, изменившим Web.config.

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

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

26 июл. 2018 г., 08:43 отAnastasios Selmanis

тогда как 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 voidOnAuthorization(AuthorizationContextfilterContext)  
    {  }
}

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

ВАШ ОТВЕТ НА ВОПРОС