Actuellement, nous avons un site où presque toutes les pages tombent dans une classe de page qui est une sous-classe System.Web.UI.Page. En général, les sous-classes contrôlent le style - en-têtes, pieds de page, etc. - les choses affichées sur cette classe de pages que nous voulons pour toutes les classes.ASP .NET Authentification basée sur les rôles vs restrictions d'accès par page (classe de pages)
Pour une classe particulière, nous vérifions certaines variables de session pour voir si l'utilisateur a accès à cette page particulière. Sinon, ils sont redirigés et dit qu'ils n'ont pas accès.
Depuis, j'ai implémenté un fournisseur de rôles personnalisé et suis en train de mettre à jour tous mes fichiers web.config.
La question s'est posée: Pourquoi ne pas implémenter les restrictions basées sur les pages dans la classe de pages au lieu de mettre en œuvre une méthodologie de fournisseur de rôles. Honnêtement, quand j'ai considéré ce sujet pour la première fois, il m'a semblé qu'il y avait un conflit entre et que les classes de pages faisaient l'autorisation. Cependant, j'ai de la difficulté à trouver des raisons pour lesquelles l'autorisation basée sur la classe page serait une mauvaise idée en ce moment.
Si vous êtes capable de comprendre de quoi je parle lorsque nous définissons les informations d'accès (autorisation) pendant le processus de connexion, puis utilisons ces informations (session) pour autoriser un utilisateur à accéder à une page basée sur la page-classe vs en utilisant la méthodologie intégrée de fournisseur de rôle ASP .NET, j'apprécierais vos réflexions sur cette question. Surtout si vous avez de l'expérience dans ce domaine.
Merci.
Vous voulez dire que vous préférez utiliser web.config et un fournisseur de rôle? – Dan7el
Oui, c'est ce que je fais. – AxelEckenberger