Autorisation et mise en cache ASP.NET MVC

Question

Je suis confus quant à la mise en cache et à l'autorisation ASP.NET MVC et j'ai un besoin urgent de clarification.

Mon attribut d'autorisation créé par moi-même hérite de AuthorizeAttribute . Sa méthode AuthorizeCore remplacée est exécutée à chaque fois, même si je définis un attribut [OutputCache] sur une action du contrôleur. Je comprends cette partie.

Maintenant, l'esprit pour moi: AuthorizeCore va échouer à chaque fois que je mets effectivement en cache la sortie et que la page est servie à partir de la mémoire cache. En effet, lorsque la demande est mise en cache, le httpContext.Session fourni avec AuthorizeCore est null !? Voici un code simplifié:

protected override bool AuthorizeCore(HttpContextBase httpContext) {
    return (Session["userId"] != null)
}

Donc si httpContext.Session est null , cela échoue évidemment à chaque fois. Je dois cependant accéder à la session. Sinon, comment puis-je vérifier si la demande est autorisée? Cela n’a aucun sens. Si cela se passe ainsi, jamais ne pourra jamais utiliser les pages en cache avec l’authentification dans ASP.NET MVC. Aide?

Answer 1

Il y a deux questions distinctes:

1. L'authentification fonctionne-t-elle avec la mise en cache dans MVC?
2. La session fonctionne-t-elle avant l'authentification en présence d'un cache (même pour les utilisateurs non authentifiés, qui ont encore une session, espérons-le, unique)?

Les réponses, respectivement, sont oui et non. L'authentification fonctionne bien avec la mise en cache. Essayez-le avec les fournisseurs d'appartenances SQL ou Domain. vous verrez.

Cependant, la mise en cache peut s’exécuter avant le module d’authentification. (Pour les points bonus: pourquoi?) L'authentification n'est appelée que si elle accroche spécifiquement le cache (comme le fait AuthorizeAttribute). no garantit que vous aurez une session dans AuthorizeCore.

Plus de points de bonus: comment cela pourrait-il changer si vous avez spécifié un nombre de variablesBbyUser dans votre configuration de cache?

Malheureusement, il est difficile de faire une authentification correcte, car il est difficile de définir un droit de sécurité. Microsoft tente de simplifier les choses avec l’API du fournisseur d’appartenance. Je vous recommande vivement d'utiliser cette lors de l'implémentation de l'authentification personnalisée. Je recommande également d'utiliser les fournisseurs intégrés et de les étendre au lieu de les réécrire autant que possible.

Autre point: le fournisseur de session ASP.NET et le fournisseur d’appartenance ASP.NET sont entièrement distincts. Différents utilisateurs peuvent partager (!) Une session et oui , vous pouvez attaquent un site de cette façon. Il est jamais prudent de placer des informations relatives à la sécurité dans une session. La sécurité est difficile.