Les formes d'authentification ne permet pas l'authentification des rôles. Cet article explique comment mettre en œuvre.
Formes d'authentification de base
L'authentification basée sur les formulaires dans ASP.NET est très utile. Au lieu d'écrire notre propre processus d'authentification, nous pouvons tout simplement changer le web.config sous system.web comme ....
<authentication mode="Forms"/>
<formes
name = "MyWebsiteCookieName"
loginUrl = "/ login.aspx"
protection = "All"
timeout = "180"
/>
</ authentification>
- Le mode d'authentification est défini sur les formes.
- Une URL est prévu pour que ASP.NET sait où, à réorienter les gens qui ont besoin de connecter!
- Un délai est indiqué en minutes. C'est "le temps depuis la dernière demande de« ne pas le «temps de connexion depuis". Si une connexion est indiqué pour être persistantes (décrit plus loin), ce n'est pas pris en compte.
- Une méthode de protection est spécifié pour le cookie.
Ensuite, je voulais spécifier un dossier dont l'accès est restreint aux personnes qui ont logged in Pour ce faire, je suis entré le code suivant dans le fichier web.config (sous <configuration>) ...
<Location path="Members">
<system.web>
<authorization>
<deny users="?"/>
</ authorization>
</ system.web>
</ location>
Cela indique que le chemin ASP.NET / membres »(le plomb / est toujours implicite) doivent refuser l'accès à tous les utilisateurs inconnus. Lorsque quelqu'un tente d'accéder à une page / Membres qu'ils sera redirigé vers l'URL que vous avez login.aspx spécifiées dans web.config.
Ce formulaire doit login.aspx demander ce que les pouvoirs que vous souhaitez (nom d'utilisateur / mot de passe par exemple) et de les valider. Une fois qu'ils ont été validés, vous n'avez pas besoin d'exécuter le code suivant à l'utilisateur redirigé vers la page elles ont été initialement essayer de accès ...
System.Web.Security.FormsAuthentication.RedirectFromLoginPage (userid, false);
Le code d'utilisateur est l'identificateur unique de l'utilisateur (nom d'utilisateur), et le second paramètre indique si Booléen ce devrait être un cookie persistant de sécurité, ou temporaire (à expiration depuis la dernière demande de page), comme indiqué précédemment.
Rôles
C'est à ce moment que j'ai réalisé que je besoin d'un / Admin dossier. Ce dossier ne doit être accessible par les administrateurs, et non pas les utilisateurs normaux. Pour cela j'ai besoin de toute évidence des rôles dans le web.config (sous <configuration>) comme ceci. ..
<Location path="Admin">
<system.web>
<authorization>
<allow roles="Admin"/>
<deny users="*"/>
</ authorization>
</ system.web>
</ location>
Note: L'ordre des autoriser ou refuser est important. Si vous refusez * (tous les utilisateurs) avant de permettre à l'administration le rôle, personne ne va avoir accès au dossier.
Le problème ici est que vous obtenez lorsque les rôles authentication mode = "Windows". Dans ce mode, chaque utilisateur a besoin d'un compte d'utilisateur Windows valide sur le serveur. Pas une bonne solution.
Heureusement, j'ai trouvé un article intéressant sur MSDN. Lorsque vous authentifier votre utilisateur dans le formulaire login.aspx, il faut alors travailler sur les rôles de l'utilisateur appartient à ...
if (author.IsAdministrator)
rôles = new String [] ( "Admin", "membre");
autre
rôles = new String [] ( "membres");/ / 1 heure de temps d'expiration de glissement
Cache.Add (author.UniqueId, les rôles, null, DateTime.MaxValue,
TimeSpan.FromHours (1), CacheItemPriority.BelowNormal, null);
J'ai créé une table contenant la chaîne de rôles que l'utilisateur possède. Elles sont ensuite stockées dans la demande [] de collecte pour des raisons de performance, sinon, nous aurions d'avoir un accès DB à chaque fois que nous voulions obtenir l'utilisateur actuel de rôles.
Maintenant, parce que les formes d'authentification n'a pas de notion de rôles ces rôles ne vont jamais dans le courant de l'utilisateur cookie. Il nous faut donc déterminer ce que ces rôles sont à chaque fois qu'une authentification est exécutée. Pour cela, nous avons besoin d'aller dans le fichier Global.asax .. .
void Application_AuthenticateRequest protégées (
Expéditeur Objet, EventArgs e)
(
if (HttpContext.Current.User! = null)
(
if (HttpContext.Current.User.Identity.AuthenticationType! = "Forms")
throw new Exception ( "Seuls les formulaires d'authentification est pris en charge, de ne pas" +
HttpContext.Current.User.Identity.AuthenticationType);System.Security.Principal.IIdentity userid =
HttpContext.Current.User.Identity;/ / Ne nous avons des rôles pour récupérer, dans l'affirmative, de remplacer l'objet utilisateur
if (Application [userId.Name]! = null)
HttpContext.Current.User = new System.Security.Principal.GenericPrincipal (
userId, (string []) Cache [userId.Name]
);
) / / utilisateur! = null
)
Cette routine vérifie que l'utilisateur courant! = Null. Cela signifie que la page est dans un endroit protégé. Si c'est le cas, alors nous utilisons les userId comme la clé de la mise en cache [] collecte de trouver une liste des rôles. Si ces rôles existent, alors nous la réaffectation de l'utilisateur en cours avec un objet que nous créons nous-mêmes, un objet qui a la liste des rôles.
Conclusion
Rôle de sécurité basés sur est très utile dans les applications Web. Avec quelques lignes de code, il est possible de mettre en œuvre une sécurité à base de rôle pour les utilisateurs sans connexion Windows valide.
Delicious
Digg
Google
Yahoo
