Dans des circonstances normales, lorsque nous gérons les droits d’accès, nous sauvegardons les informations de base de l’utilisateur après la bonne connexion dans la session, et les récupérons à chaque fois que l’utilisateur demande des données de page ou d’interface à l’avenir
Session pour voir et comparer s’il est connecté et s’il peut accéder à la page actuelle.
Le principe de Session consiste à générer un SessionID côté serveur correspondant aux données utilisateur stockées, et l’ID de session est stocké dans un cookie, que le client emportera à chaque demande
Cookie, le serveur trouve les données stockées côté serveur en fonction de l’ID de session dans le cookie.
FormsAuthentication est fourni par Microsoft pour que nous, développeurs, puissions l’utiliser pour l’authentification. Grâce à cette authentification, nous pouvons stocker le nom d’utilisateur et certaines données utilisateur sous forme de cookies,
L’authentification basique de l’identité et du rôle peut être facilement réalisée via des paramètres de condition basiques.
L’effet à obtenir ici est de mettre en place un contrôle d’accès basé sur les rôles en utilisant l’Authorize fourni par le système sans utiliser d’adhésion.
1. Création d’un ticket
Après la connexion, l’identifiant de l’utilisateur et son rôle correspondant (pour plusieurs rôles, séparés) sont stockés dans le ticket.
Chiffrez le ticket avec FormsAuthentication.Encrypt.
Stockez le ticket chiffré dans le cookie Réponse (le client js n’a pas besoin de lire ce cookie, il est donc préférable de définir HttpOnly=True pour empêcher les attaques du navigateur de voler et de forger des cookies). Ainsi, vous pourrez le lire depuis le cookie de demande la prochaine fois.
Voici une démonstration simple :
bool isPersistent, //si persister (réglé selon les besoins, si le mode persistance, le paramètre Expires du cookie doit être défini lors de l’envoi d’un cookie)
Le sixième paramètre de FormsAuthenticationTicket stocke la chaîne userData de type, où l’ID de rôle de l’utilisateur actuel est stocké, séparé par une virgule.
Lors de la connexion avec un nom d’utilisateur « test », un cookie de journal apparaît sur le client
2. Obtenir des informations sur la certification
Après la connexion, sur la page de contenu, nous pouvons obtenir les informations uname via le User.Identity.Name de la requête en cours, ou bien déchiffrer le cookie dans la requête pour obtenir le ticket, puis obtenir uname et userData (c’est-à-dire les informations d’ID de rôle précédemment stockées) à partir de celui-ci.
3. Réaliser le contrôle d’accès aux permissions via des attributs d’annotation
Configurer, activer l’authentification des formulaires et la gestion des rôles dans web.config
Lorsque nous ajoutons des propriétés d’annotation à Contrôleur et Action, où obtient-on le rôle défini ? Comme nous n’utilisons pas l’authentification basée sur l’adhésion, nous allons aussi créer un RoleProvider personnalisé. Le nom est CustomRoleProvider, hérité de RoleProvider. Voici la création de votre propre fichier CustomRoleProvider.cs dans le dossier Helper sous MVCApp.
Il existe de nombreuses méthodes abstraites dans RoleProvider, et nous n’implémentons que la méthode GetRolesForUser pour obtenir les rôles utilisateurs. Le rôle utilisateur ici peut être interrogé depuis la base de données selon l’identifiant utilisateur obtenu, ou celui stocké dans la session ou dans le cookie. Ici, j’ai déjà stocké le rôle dans les userData du ticket, donc allons le récupérer à partir du ticket.
Si nécessaire, ajoutez des attributs d’annotation au contrôleur ou à l’action validé ; par exemple, cette action ne permet l’accès qu’avec un RoleID de 1, 2 ou 3, et l’WolID de l’utilisateur actuel est (7, 1, 8), ce qui signifie que l’utilisateur a le droit d’y accéder.
P.S. :1. Le ticket est stocké à l’expiration du cookie, et si le navigateur est fermé pour se souvenir du ticket en cours, les paramètres peuvent être définis lors de l’instance du FormsAuthenticationTicket.
2. L’acquisition du Rôle peut être lue directement depuis la base de données sans être stockée dans les userData du ticket, et les userData peuvent stocker d’autres informations.
3. Si vous souhaitez configurer de manière flexible les rôles d’accès autorisés du contrôleur et d’Action, vous pouvez personnaliser la méthode OnAuthorization dans la dérogation AuthorizeAttribute, dans laquelle la méthode est utilisée
Lisez l’ID de rôle autorisé sur la page actuelle et vérifiez-le selon l’ID de rôle de l’utilisateur actuel. Ainsi, la configuration flexible du rôle est réalisée.
4. Les informations contenues dans le ticket sont finalement stockées dans le cookie, et la sécurité reste à votre discrétion, je pense personnellement qu’il vaut mieux stocker l’UserID et le RoleID dans la session.
|
Publié sur 19/07/2018 17:31:14
|
|
|
