The Same Origin Policy Documentation says this:
There is one exception to the same
origin rule. A script can set the
value of document.domain to a suffix
of the current domain. If it does so,
the shorter domain is used for
subsequent origin checks. For example,
assume a script in the document at
http://store.company.com/dir/other.html
executes the following statement:
document.domain = "company.com";
After
that statement executes, the page
would pass the origin check with
http://company.com/dir/page.html.
However, by the same reasoning,
company.com could not set
document.domain to othercompany.com.
Do all popular browsers support this? If not, which ones don't?
Firefox 2,3, IE6,7,8, Chrome, and Safari 2 and 3, Opera 9 all support document.domain;
Other "newer" browsers likely will as well, however those are the ones that I've actually tested my code (which makes use of document.domain)
Document domain should be lowercase and the rules are like this
// Actual domain is "www.foo.com"
document.domain = "foo.com"; // this is valid
// Actual domain is "bar.foo.com"
document.domain = "www.foo.com"; // this is invalid, "bar.foo.com" is not a subdomain of "www.foo.com"
// Actual domain is "blah.bar.foo.com"
document.domain = "bar.foo.com" // Ok
document.domain = "foo.com" // Still ok
document.domain = "bar.foo.com" // Invalid, you can't change it back to a more specific domain.
Related
What determines the value of document.domain property on page? It seems like it's not always equal to the root url domain.
document.domain contains the complete domain (including subdomains) from which the page was downloaded. You can set it manually to a parent domain. E.g., you can set the domain of a document loaded from subdomain.example.com to example.com. <iframe>s may have a different domain than the domain in the url bar.
I understand if we have payment.example.com and news.example.com and they both set document.domain to exmaple.com they can communicate. However, what if en.news.example.com opt-in and set document.domain=example.com? is it also possible to communicate?
Document.domain
Gets/sets the domain portion of the origin of the current document, as used by the same origin policy.
The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. It is a critical security mechanism for isolating potentially malicious documents.
Example :
// for document www.example.xxx/good.html,
// this script closes the window
var badDomain = "www.example.xxx";
if (document.domain == badDomain)
window.close(); // Just an example - window.close() sometimes has no effect.
var domain = document.domain;
Changing the value of this property is the easiest way to work around the limitations that the same origin policy applies when your pages are on different sub-domains of the same site. While JavaScript would normally consider pages from blog.example.com and from forum.example.com to be from different origins and so not allow JavaScript from one to interact with web pages from the other, you can resolve this particular restriction by setting the document.domain in both pages to the same value. By setting the document.domain to the shortest version of your domain name in all of your scripts you would allow your JavaScript to communicate across all of the pages of your site regardless of protocol, sub-domain or port.
Are there any differences between external domains, and subdomains when using EasyXDM?
I am wondering about:
Security Issues
Cross Browser Support
Speed
Anything minor or major
I really can't find much information about this, so I figure that it must be the same?
To explain further which one is the best setup of these:
example.com <-> sub.example.com
example.com <-> sub.other.com
There is one thing that make this thing easier, I found document.domain:
There is one exception to the same origin rule. A script can set the
value of document.domain to a suffix of the current domain. If it does
so, the shorter domain is used for subsequent origin checks.
For example, assume a script in the document at
http://store.company.com/dir/other.html executes the following
statement: document.domain = "company.com";
After that statement executes, the
page would pass the origin check with
http://company.com/dir/page.html. However, by the same reasoning,
company.com could not set document.domain to othercompany.com.
Source: https://developer.mozilla.org/en-US/docs/Same_origin_policy_for_JavaScript
I have a page at an internal server, server1.mydomain.com/page.jsp and another page at a different internal server, 10.x.x.x:8081/page.aspx.
On server1.mydomain.com, I set document.domain in page.jsp like this:
//page.jsp on server1.mydomain.com
document.domain = document.domain;
When I issue an alert on document.domain, it comes up as server1.mydomain.com.
On the 10.x.x.x server, I set document.domain in page.aspx, as a result, like this:
//page.aspx on 10.x.x.x
document.domain = "server1.mydomain.com";
// test if same-origin policy violation occurs
document.getElementById("div_el").innerHTML = window.top.location.href;
In Safari 5.1.5, an error pops up on the console:
SECURITY_ERR: DOM Exception 18: An attempt was made to break through the security policy of the user agent."
From what I understand, when you set document.domain, the port number is set to null; so, you have to set it on both ends, which I did. Then, this error occurs and I'm scratching my head why. Does this have anything to do with the fact I'm using 10.x.x.x and not an actual domain name?
Thank you.
You can only use document.domain to change from a more specific sub domain to a less specific domain. Like...
console.log(document.domain); // server1.mydomain.com
document.domain = 'mydomain.com'
console.log(document.domain); // mydomain.com
It can't be used to set to a more specific sub domain or to an entirely different domain.
You can only set document.domain to its current value or to a super-domain of the current setting. Thus, a page at "foo.something.com" can set it to "something.com", but not "something.else.com".
I have some JavaScript that is sharing a request between two separate servers on the same domain.
Is .com a requirement for the domain in JavaScript?
In this case both the servers are on the .abc.tyy domain with the tyy being what would normally be .com
Wondering if I can only use .com for the domain? I am getting a permission denied error, but this code works fine on other separate servers on the same domain(.com).
Updated:
Here is exactly how I'm using this:
123.abc.tyy has a script that loads properties that I want to access.
The script on 123.abc.tyy at opening script tag, sets the document.domain to 'abc.tyy'.
When I call the 'getUser()' function in 123.abc.tyy's script FROM 234.abc.tyy I am getting a permission denied error.
The way I am calling 'getUser()' is:
I access http://123.abc.tyy in a browser, and the site allows me to specify a URL to load in one of it's frames. I point that URL to http://234.abc.tyy/BeginLoadPatient.aspx" in that page I am doing the following:
window.location = 'http://234.abc.tyy/LoadPatient.aspx?PatientId=' + getUser() '; with getUser being a function originating in 123.abc.tyy
If I add 234.abc.tyy and 123.abc.tyy to my trusted sites, everything works fine - is this skipping over the same origin policy?
No, the SOP doesn't care what the domain is, only that it represents the same origin. (Could it be that you have the .com domain hard-coded somewhere?)
Note that there's more than the domain to consider. The Same Origin Policy looks at protocol, port, and host as well. So aaa.abc.tyy and bbb.abc.tyy are different origins.
If you're in control of the servers involved, you might look at Cross-Origin Resource Sharing, but unfortunately CORS is only implemented in modern browsers (and on those versions of IE where it's supported, it's only supported if you use it explicitly).
Another option, of course, is JSON-P, which has the advantage of working cross-browser right now.
Another thing to look at is document.domain, details here and here.
Update after your edits:
The script on 123.abc.tyy at opening script tag, sets the document.domain to 'abc.tyy'.
When I call the 'getUser()' function in 123.abc.tyy's script FROM 234.abc.tyy I am getting a permission denied error.
You'll need to set document.domain to "abc.tyy" in BeginLoadPatient.aspx as well.
If I add 234.abc.tyy and 123.abc.tyy to my trusted sites, everything works fine - is this skipping over the same origin policy?
I wouldn't be at all surprised (although to me it would be pretty dodgy), but have no first-hand knowledge of it. Would be easy to test.