Custom IIdentity ou IPrincipal ou autre

Question

Je trouve que dans l'application en cours avec laquelle je travaille, je récupère plusieurs entités (liées au compte des utilisateurs authentifiés) dans presque tous les contrôleurs. Ces entités sont mises en cache au niveau de la couche orm, cependant, il semble que ces entités seraient un bon candidat pour charger une fois au moment de l'authentification et ajouter quelques propriétés à l'objet IPrincipal personnalisé des applications.

Une autre option à laquelle je pensais était de créer un objet de contexte personnalisé (avec les objets de compte liés aux utilisateurs) et de le transmettre avec la requête en cours.

Avantages/inconvénients de chaque approche? Existe-t-il une autre façon de traiter les objets couramment utilisés comme celui-ci?

Answer 1

Il semble que vous manquiez le fait que l'instance de IPrincipal/IIdentity soit recréée à chaque requête. Il n'est pas conservé n'importe où si vous ne le persistez pas de manière explicite.

Je ne pense pas qu'il existe une différence de performances entre une classe principale personnalisée contenant les données et une propriété ambiante mise en cache. D'autre part, l'inconvénient d'une classe d'authentification personnalisée est que vous devez fournir un module d'authentification personnalisé afin que ces instances soient recréées au cours de l'événement AuthenticateRequest dans le pipeline de traitement. En d'autres termes, vous devrez remplacer FormsAuthenticationModule par votre propre. Ce n'est pas difficile mais je ne le ferais pas si ce n'est pas absolument nécessaire.

Notez également que certaines données peuvent être conservées dans la section UserData du cookie de formulaires. Cela signifie que vous pouvez l'avoir tant que le cookie est valide et le créer une seule fois.