Que fait document.domain = document.domain?

90

Le composant JS côté client d' Orbited (un serveur Comet) requiert 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 que tout autre JS ne soit 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.)

javascript orbited mjs
la source

Réponses:

202

J'ai en fait écrit ce code.

Lorsque vous essayez de faire une comète inter-sous-domaine / port, l'iframe doit avoir la même document.domainvaleur que la trame parent. Malheureusement, le navigateur stocke le nom de domaine ET le port en interne pour la document.domainvaleur d' origine . Mais le getter et le setter en javascript ne savent rien du port. Le problème est donc le suivant: si le cadre supérieur document.domainest ('example.com', 80), et le cadre inférieur ('comet.example.com', 80), comment obtenez-vous également le cadre inférieur ('example.com', 80)?

Vous ne pouvez pas, car la modification de la partie du nom d'hôte entraînera nécessairement la définition du port null, donc le mieux que vous puissiez faire est ('example.com', null)dans le cadre inférieur. Ainsi, le cadre supérieur doit également être défini sur cette valeur, et le paramètre document.domain=document.domainfait exactement cela. Il modifie la représentation interne dans le navigateur de ('example.com', 80)à ('example.com', null), puis tout correspond et la communication de trame entre ports / sous-domaines fonctionne.

Michael Carter
la source
Cette solution n'a malheureusement pas fonctionné pour moi (voir stackoverflow.com/questions/7796767/… pour plus de détails). L'ajout de «document.domain = document.domain» à tous les cadres ne change pas le comportement de Chrome. Des idées?
Stephen Gross
De plus, j'ai compris que si je définissais un délai pour mes js, j'obtenais au moins des URL d'apparence valide pour les deux cadres. Cependant, une image ne peut toujours pas accéder à l'autre.
Stephen Gross
6
Il y a une autre explication du fonctionnement de l'étrange port "caché" chez MDN: developer.mozilla.org/en/Same_origin_policy_for_JavaScript
mjs
1
Ah, vous êtes donc le coupable de ce morceau de code exaspérant. Grâce à cette ligne, après son exécution (et document.domain défini), tout iframe créé dynamiquement est défini comme cross-domain et donc l'iframe nouvellement créé n'est plus accessible. : /
crappish
@mjs yes: Le numéro de port est conservé séparément par le navigateur. Tout appel au setter, y compris document.domain = document.domain entraîne le remplacement du numéro de port par null. Par conséquent, on ne peut pas faire en sorte que company.com:8080 parle à company.com en définissant uniquement document.domain = "company.com" dans le premier. Il doit être défini dans les deux pour que les numéros de port soient tous les deux nuls.
Royi Namir
38

Les navigateurs font la distinction entre (a) document.domain lorsqu'il n'est pas défini explicitement et (b) document.domain lorsqu'il est défini explicitement ... même s'ils retournent 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 (sous le même domaine parent).

Si LA page parente ET le script externe définissent explicitement document.domain sur la même valeur, la restriction de politique de même origine peut être contournée et chaque script peut accéder à tous les objets et propriétés (autrement restreints) des contextes les uns des autres.

hebdomadaire
la source
9

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

Cette propriété définit ou renvoie le nom de domaine du serveur d'où provient le document. Il s'agit par défaut du nom de domaine du serveur à partir duquel le document a été récupéré, mais peut être remplacé par un suffixe (et uniquement un suffixe) de ce nom. Cela permet le partage des propriétés de script, la sécurité le permet, entre les documents fournis par différents serveurs à condition qu'ils partagent le même suffixe de domaine.

Il me semble que cela permet la création de scripts intersites pour le même domaine (même si le sous-domaine est différent).

Je suppose que si vous ne touchez pas document.domain, le moteur js n'autorise que d'autres javascripts du même domaine. Avec cette propriété, vous serez en mesure de déployer sur d'autres sous-domaines comme l'état des documents en orbite.

Miguel Ping
la source
6
Cela n'explique pas pourquoi document.domain = document.domainn'est pas un NOOP.
Crescent Fresh le
1
Juste une supposition sauvage, mais comme je l'ai dit, je suppose que la propriété n'est déclenchée que chaque fois qu'elle est définie sur une valeur.
Miguel Ping le
6

Le document.domainextrait une valeur par défaut de l'URL réelle s'il n'est pas défini explicitement. Les navigateurs enregistreront si document.domainelle provient par défaut de l'URL ou si elle a été explicitement définie. Les deux doivent être une valeur par 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'un est défini par défaut et que l'autre est défini explicitement, les deux correspondant s'ils sont lus, il sera toujours interdit aux deux pages de se parler.

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

Charlie
la source