What does document.domain = document.domain do?

Question

The client-side JS component of Orbited (a Comet server), requires that if the server is running on a different domain or port to the JS itself, you must execute

document.domain = document.domain;

before any other JS is loaded. (See the documentation.)

What does this do? It looks like a NOOP! (I've checked and it is in fact necessary.)

Coze

Answer 1

I actually wrote this code.

When trying to do cross-subdomain/port comet, the iframe needs to have the same document.domain value as the parent frame. Unfortunately, the browser stores the domain name AND port internally for the original document.domain value. But the getter and setter in javascript knows nothing about the port. So the problem is this: if the top frame document.domain is ('example.com', 80), and the bottom frame is ('comet.example.com', 80), how do you get the bottom frame to be ('example.com', 80) as well?

You can't, as changing the hostname portion will necessarily cause the port to be set to null, so the best you can do is ('example.com', null) in the bottom frame. So the top frame also needs to be set to that value, and setting document.domain=document.domain does just that. It changes the internal representation in the browser from ('example.com', 80) to ('example.com', null) and then everything matches up and cross-port/subdomain frame communication works.

Miller

This solution has unfortunately not worked for me (see #7797267 for details). Adding 'document.domain=document.domain' to all the frames doesn't change Chrome's behavior. Any ideas? – Janicejanicki

Also, I figured out that if I set a delay for my js, I at least get valid-looking URLs for both frames. Still, however, one frame can't access the other. – Janicejanicki

There's another explanation of how the strange "hidden" port works at MDN: developer.mozilla.org/en/Same_origin_policy_for_JavaScript – Coze

Ah, so you are the culprit for this infuriating bit of code. Thanks to said line, after it's been run (and document.domain set) any dynamically created iframe is set as cross-domain and thus the newly created iframe can't be accessed anymore. :/ – Lycanthropy

@Coze yes : The port number is kept separately by the browser. Any call to the setter, including document.domain = document.domain causes the port number to be overwritten with null. Therefore one can not make company.com:8080 talk to company.com by only setting document.domain = "company.com" in the first. It has to be set in both so that port numbers are both null. – Kenosis

Note that since fxsitecompat.com/en-CA/docs/2013/… you should put document.domain = document.domain in try-catch block. – Herbartian

Answer 2

Browsers distinguish between (a) document.domain when not explicitly set and (b) document.domain when explicitly set ... even if they return the same value.

Explicitly setting the value indicates intent to "cooperate" with a script on another subdomain (under the same parent domain).

If BOTH the parent page AND the external script explicitly set document.domain to the same value, the same-origin policy restriction may be bypassed and each script may access all the (otherwise restricted) objects and properties of each others' contexts.

Obtect

Answer 3

I found the following info on this site: devguru. More concretely, here's the quote:

This property sets or returns the domain name of the server from which the document originated. This defaults to the domain name of the server that the document was retreived from, but can be changed to a suffix (and only a suffix) of this name. This allows the sharing of script properties, security allowing, between documents delivered from different servers providing they share the same domain suffix.

It seems to me that it allows cross site scripting for same domain (even if subdomain is different).

I would suppose that if you don't touch document.domain, the js engine only allows other javascripts from same domain. With that property, you'll be able to deploy to other sub-domains like the orbited docs state.

Libove

That does not explain why document.domain = document.domain is not a NOOP. – Cyclopropane

Just a wild guess, but like I said I guess that the property is only triggered whenever it is set to a value. – Libove

Answer 4

The document.domain pulls a default from the actual URL if not explicitly set. Browsers will record if document.domain has come as a default from the URL or if it was explicitly set. Both must be a default for the same domain or both must be explicitly set to the same domain for this to work. If one is default and one is explicitly set, both matching if read, the two pages will still be forbidden from talking with each other.

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

Exterior