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
Related
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.
Despite of the fact that I have seen many articles (including in stackoverflow) demonstrating up how to bypass javascript's same origin policy assigning document.domain property, its not working. I also read in W3C specs that document.domain property is read-only and not all browsers accept setting it and I think that is the cause I can't get that working!
I have a page (domain d1.y.com.br) and I need to invoke a button in an embedded iframe's page (domain d2.x.com.br). I'm setting the parent document.domain attribute to subdomain 'x.com.br' but I'm still receiving the 'access denied' error message in firebug console.
I have also read about JSONP but its not the case here. I really need to interact with iframe's DOM and not only get data from there (using proxy service).
Does really exist any way to bypass same origin policy to interact with the iframe's DOM ???
The proper way to send data between iframes (especially across domains) is using postMessage(). https://developer.mozilla.org/en-US/docs/Web/API/window.postMessage
That effectively "bypasses" the problem by having the recipient of the message verify that the caller has the correct domain - based on whatever rules it wants.
The client is on domain foo.com and needs to upload (send POST XMLHttpRequest) to upload.foo.com.
This is restricted because of the same origin policy.
However, the work around that I managed to come up with is, to dynamically create iframe on foo.com opening upload.foo.com and append the JavaScript code which executes the POST request from upload.foo.com like this:
iframe.onLoad [..]
(a=(b=doc)
.createElement('script'))
.src='http://foo.com/upload.php?'+Math.random(),
b.body.appendChild(a);
void(0);
Now, to me this seems redundant: if the later is possible, my logic tells me that the former should be possible as well. Is it?
-- update
I have just noticed that there is file on the sub domain containing this:
<?xml version="1.0" ?>
<cross-domain-policy>
<allow-access-from domain="*" />
<allow-access-from domain="*.foo.com" secure="false" />
</cross-domain-policy>
Can I use it somehow to my advantage?
XMLHttpRequest is not sensitive to document.domain because the object requires mutual opt-in for security reasons, and XHR has no way of knowing what the target might want the document.domain value to be set to. In order for SiteA to interact with the DOM of a site on SiteB, both sites must share a common private domain suffix, and both must opt-in to the communication by setting document.domain to their common suffix.
Your cross-domain policy file doesn't actually make a lot of sense (as it opts-in everything, and then a subset of everything) but it's used for Flash, not XHR (which uses CORS).
I don't think it's possible to simplify this, but if it seems inelegant to you, there are simpler ways to use cross-origin JS.
Indeed, this is almost exactly what jQuery does if you try to send a request using jsonp. Wikipedia for JSONP
(Along with several other ways to bypass the same-origin restriction)
I don't know if this is what you're asking about, but in the name of maintainability, I would advise that you use the jQuery approach.
You need to set dataType: 'jsonp' and you're all set.
You can optionally set the parameter "callback=?"(look at the docs).
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.
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.