Die derzeit akzeptierte Antwort ist nicht die sicherste Lösung, weil es den Entwickler zu erfordert immer daran erinnern, dass neue Basisklasse für alle neuen Controller oder Aktionen („schwarze Liste“ zu erben, so dass Anwender alles zugreifen, es sei denn Eine Aktion ist manuell eingeschränkt). Dies verursacht insbesondere Probleme, wenn neue Entwickler, die mit Ihren Ritualen nicht vertraut sind, in das Projekt eingeführt werden. Es ist leicht zu vergessen, die richtige Controller-Klasse zu erben, wenn Sie so vorgehen, besonders nachdem Sie Ihre Augen für Wochen, Monate oder Jahre vom Projekt genommen haben. Wenn ein Entwickler vergisst zu erben, ist es nicht offensichtlich, dass im Projekt eine Sicherheitslücke besteht.
Eine sicherere Lösung für dieses Problem ist, den Zugriff auf alle Anfragen zu verweigern, dann jede Aktion mit den Rollen dekorieren, die Zugriff auf die Aktionen ("Whitelisting"; verhindert den Zugriff auf alle Benutzer, sofern manuell erlaubt). Wenn nun ein Entwickler vergisst, die richtige Autorisierung auf die weiße Liste zu setzen, werden die Benutzer Sie darüber informieren, und es ist so einfach, sich auf andere Controller zu konzentrieren, um daran zu erinnern, wie man richtigen Zugriff gewährt. Zumindest gibt es keine größere Sicherheitslücke.
In App_Start/FilterConfig.cs Datei, die FilterConfig Klasse ändern:
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" });
}
Dies macht alle Aktionen unzugänglich, wenn der Benutzer als Administrator angemeldet ist. Dann sollten Sie für jede Aktion, auf die ein anderer autorisierter Benutzer Zugriff haben soll, diese einfach mit [OverrideAuthorization] und [Authorize] dekorieren.
In Ihrer Geschäftslogik können Sie das Autorize-Attribut auf verschiedene Arten verwenden, ohne dass Sie befürchten müssen, dass nicht autorisierte Benutzer auf Funktionen zugreifen können. Unten sind einige Beispiele.
Beispiel 1 - Nur eingeloggte Administrator- und Dispatcher-Benutzer können auf die Methoden Index() Get und Post zugreifen.
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(...);
}
}
Beispiel 2 - Nur authentifizierte Benutzer werden die Index() Methode der Heimsteuerung zugreifen dürfen.
public class HomeController : Controller
{
[OverrideAuthorization]
[Authorize] //Allow all authorized (logged in) users to use this action
public ActionResult Index()
{
return View();
}
}
Beispiel 3 - Nicht authentifizierte Benutzer (d.h. anonyme Benutzer) kann unter Verwendung des [AllowAnonymous] Attribut Zugriffsverfahren gestattet werden. Dies überschreibt auch automatisch den globalen Filter, ohne das Attribut [OverrideAuthorization] zu benötigen.
// 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)
{
...
}
Beispiel 4 - Nur Administratoren haben Zugriff auf Methoden, die die [Authorize] Attribut fehlt erlaubt sein.
public class LocationsController : Controller
{
// GET: Locations
public ActionResult Index()
{
//Business logic here.
return View(...);
}
}
Einige Anmerkungen.
Sie müssen das Attribut [OverrideAuthorization] verwenden, wenn Sie den Zugriff auf eine bestimmte Aktion auf bestimmte Rollen beschränken möchten. Andernfalls werden die Attributeigenschaften [Authorize] ignoriert und nur die Standardrolle (Administrator in meinem Beispiel) wird zugelassen, auch wenn Sie andere Rollen angeben (z. B. Dispatcher usw.).) wegen des globalen Filters. Unbefugte Benutzer werden zum Anmeldebildschirm weitergeleitet.
Das Attribut [OverrideAuthorization] bewirkt, dass die Aktion den von Ihnen festgelegten globalen Filter ignoriert. Daher müssen Sie das Attribut [Authorize] erneut anwenden, wenn Sie die Überschreibung verwenden, damit die Aktion sicher bleibt.
In Bezug auf ganze Gebiete und Controller
von Bereichen zu beschränken, wie Sie auf dem Controller anstelle der einzelnen Aktionen, die [OverrideAuthorization] und [Authorize] Attribute fragen, setzen.
Siehe meinen Blogpost [Sicherung Ihrer ASP.NET MVC 3-Anwendung] (http://blogs.msdn.com/b/rickandy/archive/2011/05/02/securing-your-asp-net-mvc- 3-application.aspx) – RickAndMSFT
Siehe meinen Blog-Beitrag Sichern der ASP.NET MVC 4-App und des neuen AllowAnonymous-Attributs – RickAndMSFT
Link für Ricks letzten Kommentar -> http://blogs.msdn.com/b/rickandy/archive/2012/ 03/23/securing-your-asp-net-mvc-4-app-und-the-new-allowanonymous-attribute.aspx –