Rôles pour l'accès au service en marque blanche

Question

OK,

Je sais que je fais quelque chose de mal - mais je ne peux pas trouver une meilleure solution. Je développe un site web qui va permettre aux utilisateurs de créer leurs propres mini-sites.

Quelque chose comme Ning. En outre, j'ai seulement 1 connexion de base et l'accès à chaque site mini est fourni (en ce moment) via les rôles.

Ainsi, la façon dont je fais ce droit est maintenant:

Everytime un nouveau mini-site est créé - dire bla, je crée 2 rôles dans ma demande. blah_users et blah_admin

L'utilisateur qui crée le mini-site est donné le rôle - blah_admin et tous les autres utilisateurs qui veulent se joindre à ce mini-site (ou réseau) est donné le rôle - blah_user.

Tout le monde peut voir les données de n'importe quel site Web. Cependant, pour ajouter des données, il faut être membre de ce mini-site (le rôle blah_user doit être assigné)

Le problème auquel je fais face est que, en faisant un système basé sur les rôles, je dois faire plein de choses manuellement. Les contrôles Asp.Net 2 qui fonctionnent sur la propriété User.IsAunthenticated sont pour l'essentiel inutiles pour moi maintenant car avec la propriété IsAuthenticated, je dois également vérifier si l'utilisateur a le rôle approprié.

Je suppose qu'il existe une meilleure façon d'architecturer le système, mais je ne sais pas comment. Des idées?

Ce site est en cours de développement sous ASP.Net 2 sur IIS 6. Merci une tonne!

Answer 1

Je crains que les choses liées à des rôles standards d'ASP.NET ne soient pas ce dont vous avez besoin. Vous pouvez essayer de changer le module d'authentification pour qu'il le fasse:

1. Connectez-vous avec un cookie.
2. Déterminez les rôles de votre visiteur. Peut-être utiliserez-vous une table spéciale qui correspond à l'utilisateur et au site.
3. Crée un principal personnalisé avec les rôles utilisateur énumérés et affecte Identity et Principal à la demande en cours.

Je ne pense pas non plus que faire des rôles spéciaux pour chaque site est une bonne idée. Quand vous auriez une centaine de sites, vous auriez aussi deux cents rôles. Assez ingérable, j'ai peur. Lorsque nous résolvions une tâche similaire, nous n'utilisions tout simplement pas les contrôles standard. Nous avions un jeu de rôles unique utilisé sur tous les sites. L'adhésion à un utilisateur concret est déterminée en fonction du site actuel et de ses relations avec ce site.

Ajout: Une autre possibilité d'investigation est Application qui existe dans le système d'authentification ASP.NET. Peut-être qu'il est possible d'isoler chaque sous-site dans une application distincte?

Mise à jour: Méthode qui fonctionne pour notre application.

1. Ne faites pas beaucoup de rôles clonés. Utilisez seulement deux: utilisateurs et admin. Si vos sites sont publics, le rôle "utilisateurs" peut être global: l'utilisateur d'un site ne diffère pas de l'utilisateur d'un autre site. Si "utilisateurs" et "tout le monde" sont des rôles différents, alors bien sûr les "utilisateurs" devraient également être liés à un site.

2. Utilisez les utilisateurs d'appartenance ASP.NET standard, mais n'utilisez pas de mécanisme de rôle standard.

3. Créer un mécanisme pour stocker la relation entre le site et l'utilisateur. Il peut s'agir d'une table simple contenant l'identifiant du site, l'utilisateur et le rôle.

4. Ce que vous devez remplacer est la méthode IsInRole. (Méthode s pour être exact, je le couvrirai plus tard). Cette méthode est dans l'interface IPrinciple, vous devez donc créer votre propre objet principal. C'est assez simple.

   1. Méthode IsInRole de ce type devrait ressembler à prendre le site actuel (de HttpRequest) regarder dans la table utilisateur du site et obtenir des rôles

5. Ensuite, vous devez associer votre capital à une demande. Faites-le dans l'événement PostAuthenticateRequest.

6. Il existe également RoleProvider. Honnêtement, je ne sais pas quand il est utilisé, mais il a aussi la méthode IsInRole. Nous pouvons l'ignorer de la même manière. Mais les autres méthodes de ce fournisseur sont plus difficiles. Par exemple AddUsersToRoles. Il accepte un tableau de noms d'utilisateurs et de rôles, mais à quel contexte (site) devrait-il être ajouté? Pour courant? Pas sûr, parce que je ne sais pas quand cette méthode est appelée. Donc cela nécessite quelques expériences. Je vois (Reflector aide) que RopePrincipal en lui-même utilise RoleProvider pour récupérer la liste des rôles, alors peut-être que c'est implémenté uniquement RoleProvider, en utilisant le principal standard. Pour notre application ce n'est pas un cas, donc je ne peux pas dire quels problèmes pourraient être cachés ici.