J'ai une application avec plusieurs sous-domaines, subone.parent.com, subtwo.parent.com.
J'ai une page de connexion à parent.com/login. Lorsqu'un utilisateur se connecte, je les redirige dans le domaine approprié en fonction de laquelle ils sont membres. Cela fonctionne bien. Ceci authentifie correctement l'utilisateur pour subone.parent.com et non subtwo.parent.com. Cependant, je voudrais faire ce qui suit. Si l'utilisateur remonte à parent.com, je voudrais savoir qu'ils sont connectés et les redirigent vers Subone.parent.com. Y a-t-il une meilleure pratique pour l'accomplir? Ou est-ce que je dois mettre un autre cookie pour parent.com? Merci!
Travailler dans ASP.NET MVC Si cela compte.
3 Réponses :
Vous pouvez partager des cookies à travers les domaines comme si vous essayez de faire, mais son exemple pas droit, exemple ici .
Une autre option consiste à définir le cookie pour être ".parent.com" plutôt que de spécifier le sous-domaine explicitement et d'utiliser le magasin de cookie des détails du sous-domaine. Ensuite, vous pouvez accéder au cookie à partir de n'importe lequel de vos sous-domaines (et parent en supposant son www.parent.com).
Si votre utilisation de MVC, vous pouvez facilement créer un filtre personnalisé et ajouter aux contrôleurs www.parent.com pour rechercher l'existence du cookie, et si oui, rediriger vers le sous-domaine, le cookie spécifie. Plus de détails sur les filtres ici .
Je pense que votre deuxième option peut fonctionner ici. Je définit le domaine vers le parent. J'ai ajouté le sous-domaine sur les données utilisateur FormsAuthticket. J'ai créé une personnalité qui sera sur Isauthenciated vérifiera le domaine actuel contre lesdata. Qu'est-ce que tu penses?
Je fixerais le cookie pour le domaine explicite comme vous l'avez, car cela conserve des informations de sécurité dans ce cookie du domaine spécifique. Vous pouvez également ajouter un cookie non crypté au niveau * .parent.com qui contient des informations sur les domaines qui ont été authentifiés. Il n'y a pas de moyen réel de lier cela ensemble sans utiliser peut-être que des horodatages et d'avoir une connexion logique entre les applications (c'est-à-dire - Sub2 dispose d'un délai d'attente de session de 20 minutes de sorte que si le cheype de domaine + valide a lieu dans le cookie parent, il serait valide, Cependant, c'est la logique commerciale).
Je ne suis pas sûr du raisonnement derrière la déconnexion entre les domaines, mais vous préférez réellement avoir un seul cookie qui a crypté le texte derrière le texte crypté. Par exemple:
1) Sub1 se connecte, définit le cookie parent.com comme valide. Envoie une pièce de données utilisateur à un service Web d'authentification.
2) Le service d'authentification reconnaît Sub1 comme émetteur, chiffre les données de l'utilisateur et l'ajoute à un objet Cookie personnalisé.
3) L'objet Cookie personnalisé construit une chaîne composite sur un caractère divisé unique (ou une séquence) et la met à la disposition de la méthode de service.
4) Le service, à l'aide du cryptage des formulaires, chiffre tout le billet et le renvoie à la connexion d'origine.
De cette façon, chaque serveur serait capable de déprendre le ticket global, mais chaque pièce de données serait cryptée à l'aide d'un algorithme commun mais un sel à base de serveur. Donc, si Sub2 tente de lire les données de cookie à partir de Sub1, il reçoit la version cryptée plutôt que des données brutes.
Merci si j'ajoute un cookie d'utilisateur non crypté au niveau .Parrent, cela ne pouvait pas être modifié / spoofed pour permettre l'accès à d'autres sous-domaines?
@Paul: En quelque sorte. Je suggère 2 niveaux de cryptage. Le premier est le cryptage par défaut des formes de maîtrisation qui conserve tout votre cookie privé pour simplement le domaine * .parent.com. La seconde est un cryptage interne appliqué à chaque section privée du cookie dont le sel est connu uniquement entre le serveur principal et le serveur individuel. Chaque sous-domaine aurait accès à tout le cookie, mais ils seraient incapables de déchiffrer une section appartenant à un sous-domaine différent. FormsAuthentication.isAuthenticated entraînerait une "vraie" valeur.
@Paul: Suite - portant cela à l'esprit, vous auriez besoin d'augmenter ce chèque avec quelque chose qui valide les données dans le cookie actuel. Isauthentiqué && mycookiedata.isvalid (ticket) ou quelque chose comme ça.
Vous pouvez partager la même session sur tous les sous-domaines. C'est le code que nous utilisons pour accomplir que :-) à l'intérieur de la méthode de la page_LOPHOAD est le suivant: Ça fonctionne bien :-) robert
Merci Robert, mais je ne veux pas que l'utilisateur soit authentifié sur tous les sous-domaines, juste la seule et la racine.
Nous avons confronté à un grave problème avec cette solution: il a conservé le de la sortieCache de travail sur toutes les pages qui utilisaient un MasterPage avec ce code. Cette solution ici Fabriquée à la sortieCache fonctionne comme un charme.