2009-07-17 10 views
1

Est-ce que quelqu'un sait si je peux définir une valeur de session pour le domaine actuel, et utiliser cette session pour un autre domaine?Définir une session pour différents domaines du même serveur?

Par exemple:

quand je cette session dans le domaine www.aabc.com et je souhaite que cette session pour travailler dans le domaine www.ccc.com aussi bien - je clique sur un bouton dans www.aabc.com et changez l'en-tête à www.ccc.com?

Répondre

2

Vous ne pouvez définir des cookies pour votre domaine (et d'autres sites sur votre domaine, comme les sous-domaines, si je me souviens bien).

Ceci est (surtout?) Pour des raisons de sécurité: les autres, tout le monde pourrait créer des cookies pour tout site web ... Je vous laisse imaginer le désordre ^^

(La seule façon de définir des cookies pour un autre domaine semblent en exploitant le trou de sécurité d'un navigateur - voir http://en.wikipedia.org/wiki/Cross-site_cooking par exemple, donc, dans les cas normaux, pas possible - heureusement)

+0

désolé faites ... mes questions mettaient la session pour la différence domaine ... –

+0

Eh bien, vous avez édité votre question pour mettre "session" au lieu de "cookie" juste pendant que j'écrivais ma réponse; ma réponse reste la même, car le lien entre un utilisateur et sa session est généralement conservé dans un cookie. Comme les données de la session sont généralement conservées dans un fichier sur le serveur Web, il est encore plus difficile de les partager entre les sites Web (bien que votre serveur ne soit pas correctement sécurisé, vous pouvez accéder aux fichiers de session d'un autre site Web hébergé). dessus - mais pas bon ^^) –

2

Vous ne pouvez pas accéder directement aux deux sessions de domaines, cependant, il existe des solutions légitimes pour transmettre des données de session entre deux sites que tu contrôles. Pour les données qui peuvent être falsifiées, vous pouvez simplement avoir une page sur le domaine abc.com charger une image de 1px par 1px sur xyz.com et transmettre les données appropriées dans la chaîne de requête. Ceci est très peu sûr, alors assurez-vous que l'utilisateur ne peut rien casser en le falsifiant.

Une autre option consiste à utiliser un magasin commun quelconque. S'ils ont accès à la même base de données, il peut s'agir d'une table dans laquelle le domaine abc.com stocke un enregistrement, puis transmet l'identifiant de l'enregistrement au domaine xyz.com. C'est une approche plus appropriée si vous essayez de transmettre des informations de connexion. Assurez-vous de masquer les identifiants afin qu'un utilisateur ne puisse pas deviner un autre identifiant d'enregistrement. Une autre approche de la méthode de stockage commun si ces deux domaines se trouvent sur des serveurs différents ou ne peuvent pas accéder à la même base de données consiste à mettre en place un service de stockage de cache qui stockera des informations et sera accessible par les deux domaines. Le domaine abc.com transmet certaines données et le service renvoie un identifiant que le domaine abc.com envoie au domaine xyz.com qui retourne ensuite au service demandant les données. Encore une fois, si vous développez ce service vous-même, assurez-vous de masquer les identifiants.

3

Je devais régler ceci lors de mon dernier travail. La façon dont il a été géré était par le biais d'un passage de hachage à la main et semi-sécurisé. Fondamentalement, chaque site, site A et site B, a une configuration de passerelle identique sur chaque domaine. La passerelle accepte un user ID, un timestamp, un redirect URL et un hash. Le hash est composé d'un shared key, le timestamp, le user ID.

Le site A génère le hachage et envoie toutes les informations répertoriées ci-dessus à la passerelle sur le site B. Le site B hache ensuite les données user ID et timestamp reçues avec le shared key.

Si le hachage généré correspond au hachage reçu, la passerelle consigne l'utilisateur et charge sa session à partir d'une table de mémoire partagée ou d'un pool memcached et redirige l'utilisateur vers le redirect url reçu.

Enfin, le timestamp est utilisé pour déterminer un délai d'expiration pour le hash passé (par exemple: le hachage n'était valide que pour le temps x). Quelque chose d'environ 2,5 minutes est ce que nous avons utilisé pour notre TTL (pour tenir compte du décalage réseau et peut-être un rafraîchissement ou deux).

Les points clés sont:

  • Avoir une ressource partagée où les sessions peuvent être sérialisés
  • l'aide d'une clé partagée pour créer et confirmer hash (si vous allez utiliser md5, faire des passes multiples
  • Autorisez uniquement le hachage pour une durée limitée mais raisonnable.
  • Cela nécessite le contrôle des deux domaines.

Espérons que cela a été utile.

Questions connexes