В настоящее время принятый ответ не является самым безопасным решением, поскольку он требует от разработчика всегда не забывать наследовать этот новый базовый класс для любых новых контроллеров или действий («черный список»; предоставляя пользователям доступ ко всему, если только действие ограничено вручную). Это особенно вызывает проблемы, когда к проекту знакомятся новые разработчики, незнакомые с вашими ритуалами. Легко забыть унаследовать надлежащий класс контроллера, если это сделать таким образом, особенно после того, как вы отвлеклись от проекта на недели, месяцы или годы. Если разработчик забывает наследовать, не очевидно, что в проекте есть уязвимость безопасности.
Более безопасное решение этой проблемы состоит в том, чтобы запретить доступ к всем запросам, а затем украсить каждое действие ролями, которым разрешен доступ к действиям («белый список»; запрещен доступ для всех пользователей, кроме как вручную). позволил). Теперь, если разработчик забудет внести в белый список правильную авторизацию, пользователи сообщат вам об этом, и это так же просто, как посмотреть на другие контроллеры для напоминания о том, как предоставить надлежащий доступ. Однако, по крайней мере, нет существенной уязвимости безопасности.
В файле App_Start / FilterConfig.cs измените класс FilterConfig:
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
...
//Deny access to all controllers and actions so that only logged in Administrators can access them by default
filters.Add(new System.Web.Mvc.AuthorizeAttribute() { Roles = "Administrator" });
}
Это делает все действия недоступными, если пользователь не вошел в систему как администратор. Затем для каждого действия, к которому вы хотите, чтобы у другого авторизованного пользователя был доступ, вы просто украшаете его [OverrideAuthorization] и [Authorize].
.
В вашей бизнес-логике это позволяет вам использовать атрибут Authorize различными способами, не беспокоясь о том, что неавторизованные пользователи могут получить доступ к каким-либо функциям. Ниже приведены некоторые примеры.
Пример 1 - Доступ к Index() методам Get и Post имеют только зарегистрированные пользователи Администратор и Диспетчер.
public class MarkupCalculatorController : Controller //Just continue using the default Controller class.
{
// GET: MarkupCalculator
[OverrideAuthorization]
[Authorize(Roles = "Administrator,Dispatcher")]
public ActionResult Index()
{
//Business logic here.
return View(...);
}
// POST: DeliveryFeeCalculator
[HttpPost]
[ValidateAntiForgeryToken]
[OverrideAuthorization]
[Authorize(Roles = "Administrator,Dispatcher")]
public ActionResult Index([Bind(Include = "Price,MarkedupPrice")] MarkupCalculatorVM markupCalculatorVM)
{
//Business logic here.
return View(...);
}
}
Пример 2 - Только авторизованным пользователям будет разрешен доступ к методу Index() контроллера Home.
public class HomeController : Controller
{
[OverrideAuthorization]
[Authorize] //Allow all authorized (logged in) users to use this action
public ActionResult Index()
{
return View();
}
}
Пример 3 - Неаутентифицированным пользователям (т.е. анонимным пользователям) может быть разрешен доступ к методам с помощью атрибута [AllowAnonymous]. Это также автоматически переопределяет глобальный фильтр без использования атрибута [OverrideAuthorization].
// GET: /Account/Login
[AllowAnonymous]
public ActionResult Login(string returnUrl)
{
ViewBag.ReturnUrl = returnUrl;
return View();
}
//
// POST: /Account/Login
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)
{
...
}
Пример 4 - Только администраторам будет разрешен доступ к методам, у которых отсутствует атрибут [Authorize].
public class LocationsController : Controller
{
// GET: Locations
public ActionResult Index()
{
//Business logic here.
return View(...);
}
}
Некоторые заметки.
Вы должны использовать атрибут [OverrideAuthorization], если хотите ограничить доступ к определенному действию для определенных ролей. В противном случае свойства атрибута [Authorize] будут игнорироваться, и будет разрешена только роль по умолчанию (администратор в моем примере), даже если вы указываете другие роли (например, диспетчер и т. Д.) Из-за глобального фильтра. Любые неавторизованные пользователи будут перенаправлены на экран входа в систему.
При использовании атрибута [OverrideAuthorization] действие игнорирует установленный вами глобальный фильтр. Следовательно, вы должны повторно применять атрибут [Authorize] каждый раз, когда используете переопределение, чтобы действие оставалось безопасным.
Относительно целых областей и контроллеров
Для ограничения по областям, как вы просите, поместите атрибуты [OverrideAuthorization] и [Authorize] на контроллер вместо отдельных действий.