1) Pour ecriture d'un MembershipProvider ou d'un RoleProvider personnalisé : Il faut grader à l'esprit qu'il s'agit d'un provider, en soit il ne log pas votre utilisateur, il sert juste à répondre aux questions que se posent les controls qui servent à l'authentification. Il faut donc pas chercher à trop en faire avec ceux-si, les méthodes suivantes sont largemnt suffisantes pour permettre l'emploi de vos providers avec ces controles (tant que vous en cherchez pas à modifier vos utilisateurs)
public class CustomMembershipProvider : MembershipProvider
{
#region Obligatoires
///
/// Rechercher un utilisateur par son login
///
///
///
///
///
///
public override MembershipUserCollection FindUsersByName(String userNameToMatch, Int32 pageIndex, Int32 pageSize, out Int32 totalRecords)
{
// ...
}
///
/// Retourne un utilisateur
///
///
///
///
public override MembershipUser GetUser(Object providerUserKey, Boolean userIsOnline)
{
// ...
}
///
/// Retourne un utilisateur
///
///
///
///
public override MembershipUser GetUser(String username, Boolean userIsOnline)
{
// ...
}
///
/// Valider un utilisateur avec son login et son mot de passe
///
///
///
///
public override Boolean ValidateUser(String userName, String passWord)
{
// ...
}
#endregion
}
2) Indiquer les providers à utiliser : le code suivant est bien suffisant, donc nul besoin de ces deux ou trois kilomètres de codes comme on peut en voire un peu partout. On parle ici de sécurisé un accès, il ne faut donc pas pécher par excès en cherchant encore ici à trop en faire.
<membership defaultprovider="CustomMembershipProvider">
<providers>
<add name="CustomMembershipProvider" type="Namespace.CustomMembershipProvider" />
</providers>
</membership>
<rolemanager defaultprovider="CustomRoleProvider" enabled="true">
<providers>
<add name="CustomRoleProvider" type="Namespace.CustomRoleProvider" />
</providers>
</rolemanager>
<authentication mode="Forms">
<forms loginurl="~/Login.aspx" />
</authentication>
<authorization>
<deny users="?" />
</authorization>
3) Autoriser ou interdire des accès: Presque tout le monde connaît les balises <authorization> avec allow et deny, mais trop souvant on croit quelles se limitent à autoriser ou interdire un répertoire. Sachez que l'on peut faire la même chose avec des fichiers.
Par exemple : pour autoriser l'accès aux thèmes si votre page login.aspx se trouve à la racine de votre site mais que vous ne souhaitez pas rendre les autres pages accessible. Sans quoi on se retrouve avec une page de longin vraiment moche... certain diront "sobre".
<location path="App_Themes">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
4) Surtout ne rien toucher d'autre! : pourquoi puis-je bien vouloir à tout pris dire cela ? ... et bien pour une raison simple, les controls d'authentification (Login, LoginStatus et autres) fonctionnent bien du moment que nos provider sont bien codées. Si vous commencez à avoir besoin de changer un de ces controls, c'est bien souvent du fait que l'un de vos provider ne répond pas correctement aux sollicitations des control et non pas le contraire!
Il n'y a pas de mal à n'avoir que le control suivant dans une page de login et rien en code-behind:
<asp:Login runat="server" ID="Login1"> </asp:Login>
Il n'y a pas de déshonneur à laisser des controls tout faire, du moment qu'ils sont faits pour cela.
Je sais que je me répète comme un grand-père, mais pour une bonne pratique de la gestion d'accès via "Froms" ou autres provider rien ne vaudra jamais le fais d'utiliser ce qui est déjà éprouvé car ce serra toujours plus stable et sécurisé qu'une mamaille personnel dont les jours sont comptés ... car il y aura toujours un petit malin pour trouver la faille dans votre code.