Question

J'ai parcouru mon code un million de fois et je ne trouve pas de problème avec ma mise en œuvre.

dans Personnalisé Authorizeattribute i Showewrobre 2 Méthodes

    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        if (!httpContext.Request.IsAuthenticated)
            return false;
        var routeData = httpContext.Request.RequestContext.RouteData;
        var ctrl = routeData.Values["controller"].ToString();
        var action = routeData.Values["action"].ToString();
        var user = httpContext.User.Identity.Name;
        _logger.Info("[logging all the details]");
        return ctrl == "SomeController";
    }

    protected override void HandleUnauthorizedRequest(AuthorizationContext ctx)
    {
        ctx.Result = new ViewResult  { ViewName = "Unauthorized" };
        // base.HandleUnauthorizedRequest(ctx);
     }

La logique d'autorisation est moquée de renvoyer false uniquement sur un contrôleur spécifique et je suis entré à travers cela pour vérifier que cela fonctionne correctement.

Le code ci-dessus causera une boucle infinie.Dans mon journal, je peux voir que la ligne a frappé 666 fois (coïncidence?) ..

Si je appelle la base de l'environnement.HandleUnauthoriséRequest (CTX), tout ce que je reçois est une page vierge.donc j'ai réfléchi à ce que la base fait, et c'est ce

filterContext.Result = new HttpUnauthorizedResult();

Cela explique pourquoi il rend une page vierge au lieu de rediriger à non autorisé.cshtml.Ce que je ne suis pas sûr, c'est pourquoi ça va dans une boucle infinie si je n'appelle pas la base.

P.s.

J'ai vérifié que si je mets la mauvaise vue non autorisée, il sera erroné (mais reste toujours indéfiniment)

 System.InvalidOperationException: The view 'Unauthorized11' or its master was not found or no view engine supports the searched locations

Était-ce utile?

La solution

Voici la mise en œuvre que j'ai fini par aller avec et cela fonctionne très bien.

    public override void OnAuthorization(AuthorizationContext filterContext)
    {

        base.OnAuthorization(filterContext);

        // this is overriden for kendo menus to hide 
        var ctrl = filterContext.RequestContext.RouteData.GetRequiredString("controller");
        var action = filterContext.ActionDescriptor.ActionName;

        [custom authorization logic on action/ctrl]

        // useful to determine if it's authorizing current controller path or menu links
        var path = filterContext.HttpContext.Request.PhysicalPath;
        _authorizingCurrentPath = path.Contains(ctrl) || path.EndsWith("WebUI") ;


        if (userAuth < requiredAuth)
            HandleUnauthorizedRequest(filterContext);
    }


    protected override void HandleUnauthorizedRequest(AuthorizationContext ctx)
    {
        if (!ctx.HttpContext.User.Identity.IsAuthenticated)
            base.HandleUnauthorizedRequest(ctx);
        else {
            if (_authorizingCurrentPath) {
                // handle controller access
                ctx.Result = new ViewResult { ViewName = "Unauthorized" };
                ctx.HttpContext.Response.StatusCode = 403;
            }
            else {
                // handle menu links
                ctx.Result = new HttpUnauthorizedResult();
                ctx.HttpContext.Response.StatusCode = 403;
            }
        }
    }

Autres conseils

La mise en œuvre par défaut de Authorizeattribute définit la réponse sur le contexte d'action, en n'appelant pas à la base de la réponse, la réponse n'est jamais définie qui provoque la répétition du filtre pour répéter le processus d'autorisation jusqu'à ce qu'une réponse soit définie (d'où la boucle infinie).

Vous pouvez voir cette logique dans le AuthorisationFilterattribute classe dont l'AuthorizeTroBute dérive de.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top