Je nage dans les relations et les hiérarchies d'une application Web que j'essaie de sécuriser avec des fournisseurs de rôles et d'appartenances sql personnalisés. Je suis un peu flou sur l'authentification des formulaires, les principaux, et autres. So -Authentification des rôles, des membres, des profils, des principaux et des formulaires
Le fichier web.config est configuré pour l'authentification par formulaires avec un fournisseur d'appartenances personnalisé et un fournisseur de rôles personnalisés. Lorsque mon application Web fictive démarre, elle valide les connexions utilisateur à partir de la base de données en utilisant les méthodes de mon fournisseur d'appartenances personnalisées.
À ce stade, je suppose qu'il colle le providerUserKey dans un objet principal qui est stocké, crypté, dans un cookie? Si je souhaite inclure d'autres informations sur un utilisateur dans une page, par exemple une clé étrangère (ID), sur une autre table de mon système existant, quel est le meilleur moyen de le conserver pour éviter d'effectuer un tri dans la base de données? Est-ce que j'étend le principe pour inclure ce champ supplémentaire? Dois-je étendre l'objet d'adhésion pour inclure ce champ supplémentaire? Puis-je créer un fournisseur de profils personnalisé et l'utiliser pour stocker le champ supplémentaire?
Où sont stockées toutes ces informations identifiables? J'avais supposé qu'un fournisseur de profil personnalisé serait accessible sans un aller-retour de base de données une fois que l'utilisateur se serait connecté.