Que fait document.domain = document.domain?

Question

Le composant JS côté client d' Orbited (un serveur Comet) nécessite que, si le serveur s'exécute sur un domaine ou un port différent du JS lui-même, vous devez exécuter

 document.domain = document.domain;
 

avant tout autre JS est chargé. (Voir la documentation .)

Qu'est-ce que cela fait? Cela ressemble à un NOOP! (J'ai vérifié et c'est en fait nécessaire.)

Answer 1

J'ai vraiment écrit ce code.

Lorsque vous essayez de faire du ski-de-domaine/port de la comète, l'iframe doit avoir le même document.domain de la valeur en tant que parent cadre. Malheureusement, le navigateur enregistre le nom de domaine ET le port interne de l'original, document.domain de la valeur. Mais les getter et setter en javascript ne sait rien sur le port. Le problème est donc le suivant: si le cadre supérieur, document.domain est ('example.com', 80), et le cadre inférieur est ('comet.example.com', 80), comment voulez-vous obtenir le châssis inférieur à ('example.com', 80) ?

Vous ne pouvez pas, que de changer le nom d'hôte de la partie qui sera nécessairement provoquer le port à régler à l' null, donc le mieux que vous pouvez faire est d' ('example.com', null) dans le cadre du bas. Donc, le cadre supérieur doit également être réglé sur cette valeur, et en définissant document.domain=document.domain . Il modifie la représentation interne dans le navigateur à partir d' ('example.com', 80) de ('example.com', null) et puis tout les matchs up et cross-port/sous-domaine du cadre de la communication des œuvres.

Answer 2

La distinction entre les navigateurs (a) le document.domaine lorsqu'il n'est pas explicitement définie et (b) du document.domaine au moment de définir explicitement ... même s'ils renvoient la même valeur.

La définition explicite de la valeur indique l'intention de "coopérer" avec un script sur un autre sous-domaine (dans le même domaine parent).

Si le parent titulaire de la page ET le script externe de définir explicitement le document.domaine à la même valeur, la même origine, la politique de restriction peut être contourné et chaque script peut accéder à tous les (restreint) des objets et des propriétés des uns et des autres contextes.

Answer 3

J'ai trouvé les informations suivantes sur ce site: devguru. Plus concrètement, voici la citation:

Cette propriété définit ou renvoie le le nom de domaine du serveur à partir duquel l'origine du document. Par défaut, c'est pour le nom de domaine du serveur le document a été récupérées à partir, mais peut être modifié pour un suffixe (et seulement un suffixe) de ce nom. Cela permet à l' le partage de propriétés de script, de la sécurité permettant, entre l'envoi de documents à partir de différents serveurs à condition qu'ils partager le même suffixe de domaine.

Il me semble qu'il permet de cross site scripting pour les même domaine (même si le sous-domaine est différent).

Je suppose que si vous ne touchez pas le document.domaine, la js moteur permet à d'autres scripts javascript à partir d'un même domaine. Avec cette propriété, vous serez en mesure de déployer à d'autres sous-domaines comme la orbité autour de docs de l'état.

Answer 4

L' document.domain tire une valeur par défaut à partir de l'URL si pas explicitement définie. Les navigateurs enregistrement si document.domain a une valeur par défaut à partir de l'URL ou si elle a été explicitement définie. Les deux doivent être un défaut pour le même domaine ou les deux, doivent être explicitement définis sur le même domaine pour que cela fonctionne. Si l'on est par défaut et est défini explicitement, deux correspondants si la lecture se fait en deux pages et sera toujours interdit de parler les uns avec les autres.

Voir: https://developer.mozilla.org/en-US/docs/DOM/document.domain