ActionFilterAttribute, gelten für Aktionen eines bestimmten controller-Typ

Ich bin mit einem ActionFilterAttribute zu tun, die benutzerdefinierte Authentifizierung Logik. Das Attribut wird nur verwendet werden, auf einer abgeleiteten Controller-Klasse, die enthält meine Authentifizierung Logik.

Hier mein Controller, abgeleitet von meinem custom controller-Klasse, und eine Beispiel-Eigenschaft:

public class MyController : CustomControllerBase
{

   [CustomAuthorize(UserType = UserTypes.Admin)]
   public ActionResult DoSomethingSecure()
   {
      return View();
   }

}

Hier ist ein Beispiel meiner ActionFilterAttribute:

public class CustomAuthorizeAttribute : ActionFilterAttribute
{
   public MyUserTypes UserType { get; set; }

   public override void OnActionExecuting(ActionExecutingContext filterContext)
   {
      myUser user = ((CustomControllerBase)filterContext.Controller).User;

      if(!user.isAuthenticated)
      {
         filterContext.RequestContext.HttpContext.Response.StatusCode = 401;
      }
   }
}

Funktioniert Super.

Hier ist die Frage: Kann ich verlangen, dass dieses Attribut NUR verwendet werden, auf Aktionen, auf meiner eigenen controller-Typ?

Ihr Attribut ist gebrochen, weil es keine Erben aus AuthroizeAttribute und somit ist nicht garantiert ausgeführt, wenn die Aktion gespeichert ist. Siehe blogs.teamb.com/craigstuntz/2009/09/09/38390, die Lösungen für die Arbeit mit caching.
Warum sollte das Ergebnis einer Aktion zwischengespeichert werden?
Es würde zwischengespeichert werden, weil jemand gesagt, es zwischengespeichert werden. Stell dir vor, jemand legt die Cache-Attribut in einer parent-Klasse, nicht zu bemerken, die gebrochen Attribut des Subtyps. Es ist eine weitaus bessere Idee, ein Attribut verwenden, das ist nicht grundsätzlich unvereinbar mit ASP.NET/MVC -caching. Siehe den link oben für weitere Optionen.
Guten Fang. Ich nicht wirklich ein Blick auf die action-filter selbst. Er ist richtig, wenn Sie schreiben Sie Ihre eigene Autorisierungs-action filter, die Sie wirklich Erben sollte aus AuthorizeAttribute. Dann können Sie das überschreiben der AuthorizeCore() protected-Methode.
Muss einige Klarstellungen zu diesem Thema hier stackoverflow.com/questions/1441799/...

InformationsquelleAutor Peter J | 2009-09-17

  1. 15

    Können Sie die ActionFilter für die Klasse selbst. Alle Aktionen in der Klasse erkennen, die ActionFilter.

    [CustomAuthorize]
public class AuthorizedControllerBase : CustomControllerBase
{
}

public class OpenAccessControllerBase : CustomControllerBase
{
}

public class MyRealController : AuthorizedControllerBase 
{
    //GET: /myrealcontroller/index
    public ActionResult Index()
    {
        return View();
    }
}
    Ich bin gerade dabei die route festzulegen, ActionFilter innerhalb der Klasse (also es ist nicht verfügbar auf anderen Klassen.) Es ist gut zu wissen, dass das Attribut kann definiert werden über ALLE ActionResults in einem controller.

    InformationsquelleAutor Jarrett Meyer

  2. 7

    Basierend auf die Kommentare und die Einschränkungen meines Systems, habe ich einen hybrid-Ansatz. Grundsätzlich, wenn die Anfrage kommt, werden über eine Cache-route oder die "Benutzer" nicht gesetzt ist, aus irgendeinem Grund schlägt die Authentifizierung fehl, in der richtigen Weise.

    public class CustomAuthorizeAttribute : AuthorizeAttribute
{
  private MyUser User { get; set; }

  public override void OnAuthorization(AuthorizationContext filterContext)
  {
    //Lazy loads the user in the controller.
    User = ((MyControllerBase)filterContext.Controller).User;

    base.OnAuthorization(filterContext);
  }

  protected override bool AuthorizeCore(HttpContextBase httpContext)
  {
    bool isAuthorized = false;
    string retLink = httpContext.Request.Url.AbsolutePath;

    if(User != null)
    {
      isAuthorized = User.IsValidated;
    }

    if (!isAuthorized)
    {
      //If the current request is coming in via an AJAX call,
      //simply return a basic 401 status code, otherwise, 
      //redirect to the login page.
      if (httpContext.Request.IsAjaxRequest())
      {
        httpContext.Response.StatusCode = 401;
      }
      else
      {
        httpContext.Response.Redirect("/login?retlink=" + retLink);
      }
    }

    return isAuthorized;
  }
}
    Wenn Sie umleiten in "isAuthorized=false" zutrifft, dann warum gehst du nicht einfach return true am Ende?
    Im Fall der IsAjaxRequest fließt, wird der user nicht umgeleitet werden, so dass die Methode immer noch zurückgeben muss.
    +1 für die Verwendung AuthorizeAttribute statt ActionFilterAttribute. Löst das problem, dass die controller-Aktion, hat die CustomAuthotize Attribut ausgeführt wird, selbst wenn wir noch nicht angemeldet sind, die andere Probleme verursachen.

    InformationsquelleAutor Peter J

Schreibe einen Kommentar