What does document.domain = document.domain do?

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.)

Solution 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.

Solution 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.

Solution 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.

Solution 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