By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,985 Members | 1,777 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,985 IT Pros & Developers. It's quick & easy.

Communicating via javascript across domains

P: n/a
Hey all,

Here's the situation:

- two websites, one on domain1 and the other on domain2
- domain1 opens a new window which is a javascript app from domain2
- domain1 needs to communicate with the javascript app on domain2

The problem occurs in that last step. Browsers don't allow script access
across domains for security reasons, rightly so. Nonetheless, I still
need to communicate with the application. I can reload the window
passing the necessary commands through the url, but this is slow because
the whole javascript app must reload.

Anyone have any ideas about a way around this limitation that would be
semi-efficient, at least more efficient than reloading the app? Signing
the script isn't an option for cost reasons. I have control over both
sites, so I can do anything that needs to be done.

Regards,
Craig
Jul 20 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Craig wrote:
Hey all,

Here's the situation:

- two websites, one on domain1 and the other on domain2
- domain1 opens a new window which is a javascript app from domain2
- domain1 needs to communicate with the javascript app on domain2

The problem occurs in that last step. Browsers don't allow script access
across domains for security reasons, rightly so. Nonetheless, I still
need to communicate with the application. I can reload the window
passing the necessary commands through the url, but this is slow because
the whole javascript app must reload.

Anyone have any ideas about a way around this limitation that would be
semi-efficient, at least more efficient than reloading the app? Signing
the script isn't an option for cost reasons. I have control over both
sites, so I can do anything that needs to be done.

Regards,
Craig


Well, it is not a cross-browser solution, but if you use HyperText
Applications (HTA), you can bypass some security. I did something like
that when I wanted a DOM inspector for IE. Unfortunately HTA only works
in IE. I think there are similar browser-specific solutions for other
systems, but I dont know offhand. You can read more about HTA at:
http://msdn.microsoft.com/workshop/a...node_entry.asp

Brian
Jul 20 '05 #2

P: n/a
In article <Ce*******************@news20.bellglobal.com>,
craig@_netscene.org enlightened us with...

Anyone have any ideas about a way around this limitation that would be
semi-efficient, at least more efficient than reloading the app?


Cookies.
Not the best, but better than nothing.
--
--
~kaeli~
If a book about failures doesn't sell, is it a success?
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 20 '05 #3

P: n/a
> - two websites, one on domain1 and the other on domain2
- domain1 opens a new window which is a javascript app from domain2
- domain1 needs to communicate with the javascript app on domain2

The problem occurs in that last step. Browsers don't allow script access
across domains for security reasons, rightly so. Nonetheless, I still
need to communicate with the application. I can reload the window
passing the necessary commands through the url, but this is slow because
the whole javascript app must reload.


If the sites share a common domain, then you can make it work. For
example, if you have 'domain1.commom.com' and 'domain2.common.com', you
can put the following in the <head>s:

document.domain = 'common.com';

This will get around the same site rule.

http://www.crockford.com/

Jul 20 '05 #4

P: n/a
Le Wed, 04 Feb 2004 11:47:58 -0600, kaeli a écrit*:
In article <Ce*******************@news20.bellglobal.com>,
craig@_netscene.org enlightened us with...

Anyone have any ideas about a way around this limitation that would be
semi-efficient, at least more efficient than reloading the app?


Cookies.
Not the best, but better than nothing.
--

I think cookies have the same domain limitations than window object ones !
Jul 20 '05 #5

P: n/a
Douglas Crockford wrote:
- two websites, one on domain1 and the other on domain2
- domain1 opens a new window which is a javascript app from domain2
- domain1 needs to communicate with the javascript app on domain2

The problem occurs in that last step. Browsers don't allow script
access across domains for security reasons, rightly so. Nonetheless,
I still need to communicate with the application. I can reload the
window passing the necessary commands through the url, but this is
slow because the whole javascript app must reload.

If the sites share a common domain, then you can make it work. For
example, if you have 'domain1.commom.com' and 'domain2.common.com', you
can put the following in the <head>s:

document.domain = 'common.com';

This will get around the same site rule.

http://www.crockford.com/

They don't share a common domain, thanks though.
Jul 20 '05 #6

P: n/a
Patricio Stegmann wrote:
Le Wed, 04 Feb 2004 11:47:58 -0600, kaeli a écrit :

In article <Ce*******************@news20.bellglobal.com>,
craig@_netscene.org enlightened us with...
Anyone have any ideas about a way around this limitation that would be
semi-efficient, at least more efficient than reloading the app?


Cookies.
Not the best, but better than nothing.
--


I think cookies have the same domain limitations than window object ones !


Yup they do. Otherwise you'd have sites looking at all your cookies
trying to scrap information.
Jul 20 '05 #7

P: n/a
Brian Genisio wrote:
Craig wrote:
Hey all,

Here's the situation:

- two websites, one on domain1 and the other on domain2
- domain1 opens a new window which is a javascript app from domain2
- domain1 needs to communicate with the javascript app on domain2

The problem occurs in that last step. Browsers don't allow script
access across domains for security reasons, rightly so. Nonetheless,
I still need to communicate with the application. I can reload the
window passing the necessary commands through the url, but this is
slow because the whole javascript app must reload.

Anyone have any ideas about a way around this limitation that would be
semi-efficient, at least more efficient than reloading the app?
Signing the script isn't an option for cost reasons. I have control
over both sites, so I can do anything that needs to be done.

Regards,
Craig

Well, it is not a cross-browser solution, but if you use HyperText
Applications (HTA), you can bypass some security. I did something like
that when I wanted a DOM inspector for IE. Unfortunately HTA only works
in IE. I think there are similar browser-specific solutions for other
systems, but I dont know offhand. You can read more about HTA at:
http://msdn.microsoft.com/workshop/a...node_entry.asp

Brian

I've never heard of this. I'll look into it. Cross-browser
compabibility is important however, so I do need to cover my bases.

Thanks
Jul 20 '05 #8

P: n/a
>>> - two websites, one on domain1 and the other on domain2
- domain1 opens a new window which is a javascript app from domain2
- domain1 needs to communicate with the javascript app on domain2 The problem occurs in that last step. Browsers don't allow script
access across domains for security reasons, rightly so. Nonetheless,
I still need to communicate with the application. I can reload the
window passing the necessary commands through the url, but this is
slow because the whole javascript app must reload.
If the sites share a common domain, then you can make it work. For
example, if you have 'domain1.common.com' and 'domain2.common.com',
you can put the following in the <head>s: document.domain = 'common.com'; This will get around the same site rule.
They don't share a common domain, thanks though.


If you have control over one of the servers, you can have it act as a
client, snatching up the page from the other site, and then relaying it
to the browser itself.

http://www.crockford.com/
Jul 20 '05 #9

P: n/a
Craig <craig@_netscene.org> wrote in message news:<Ce*******************@news20.bellglobal.com> ...
Hey all,

Here's the situation:

- two websites, one on domain1 and the other on domain2
- domain1 opens a new window which is a javascript app from domain2
- domain1 needs to communicate with the javascript app on domain2


Craig

You could try to pass the information as a query string in the URL.

Youy could either assemble a query string with JS or use a hidden form
that submits using the get method.

In a web page in domain1:

<form name="myForm" action="http://domain2/page2.html" method="get"
target="whatever">
<input name="x" value="" type="hidden">
<input name="y" value="" type="hidden">
</form>

To open the new window named "whatever" and pass over the info x=23
and y="abc":
document.myForm.x.value=23;
document.myForm.y.value="abc";
document.myForm.submit();

This should open the web page http://domain2/page2.html?x=23&y=abc
in the window called "whatever".

Alternatively assemble the query string above and use it as the url
for your window.open command.

In the web page http://domain2/page2.html you need to decode the
search string (and here's code based on "something I prepared
earlier").

var submission=self.location.search.substring(1,self.l ocation.search.length);
// remove "?" at start of query string
var nameValuePairs = new Array();
var oneNameValuePair = new Array();
var names = new Array();
var values = new Array();
var name;
var value;
var newName;
var punctuator="&"; // use "&" for query string or ";" for cookies
nameValuePairs = submission.split(punctuator); // split into
name=value pairs
for (var i in nameValuePairs) {
oneNameValuePair = nameValuePairs[i].split('=');
// separate name and value
if (oneNameValuePair[0].length>0) { // if a name to left of = sign
name = unescape( oneNameValuePair[0] ).split("+").join(" ");
value = unescape( oneNameValuePair[1] ).split("+").join(" ");
// remove url encoding
newName = true;
for (var j in names) if (name == names[j]) newName = false;
if (newName) {
names[names.length] = name;
values[name] = value; // single value with this name
} else {
values[name] = values[name] +","+value;
// comma separated list of multiple values with this name
}
}
}

This gives (I hope) an array in domain2 web page called names
containing "x" & "y" and an associative array called values where
values["x"] is "23" and values["y"] is "abc".

I've taken the above code from something I've used/tested previously
but modified it without testing - CAVEAT EMPTOR.

Hope that's of some use.

Mark
Jul 20 '05 #10

P: n/a
Craig <craig@_netscene.org> wrote in message news:<Ce*******************@news20.bellglobal.com> ...
The problem occurs in that last step. Browsers don't allow script access
across domains for security reasons, rightly so. Nonetheless, I still
need to communicate with the application. I can reload the window
passing the necessary commands through the url, but this is slow because
the whole javascript app must reload.


Craig

Oops, just read the above part of your posting.

Sorry, I think I just suggested what you already know.

A messy ugly suggestion to avoid reloading your whole JavaScript web
page:
put your web page in domain2 in a frameset,
pass the info using get to another small web page on domain2 in the
frameset
(triggering fast reload of a small page?),
use JavaScript to access variables in small web page in frameset from
you main application.

Franmeset might be two rows, one of which is zero pixel high for small
web page.

Mark
Jul 20 '05 #11

P: n/a
gr*********@yahoo.co.uk wrote:
Craig <craig@_netscene.org> wrote in message news:<Ce*******************@news20.bellglobal.com> ...

The problem occurs in that last step. Browsers don't allow script access
across domains for security reasons, rightly so. Nonetheless, I still
need to communicate with the application. I can reload the window
passing the necessary commands through the url, but this is slow because
the whole javascript app must reload.

Craig

Oops, just read the above part of your posting.

Sorry, I think I just suggested what you already know.

A messy ugly suggestion to avoid reloading your whole JavaScript web
page:
put your web page in domain2 in a frameset,
pass the info using get to another small web page on domain2 in the
frameset
(triggering fast reload of a small page?),
use JavaScript to access variables in small web page in frameset from
you main application.

Franmeset might be two rows, one of which is zero pixel high for small
web page.

Mark


That sounds like a feasible solution. Domain2 as it were, is already
composed of many frames. I'm just wondering if the same problem will
exist by trying to change the location of that frame on domain2 from
domain1.

I'll give it a try,

Thanks
Jul 20 '05 #12

P: n/a
In article <DF*******************@news20.bellglobal.com>,
craig@_netscene.org enlightened us with...

I think cookies have the same domain limitations than window object ones !


Yup they do. Otherwise you'd have sites looking at all your cookies
trying to scrap information.


Then how do people use "third party cookies"?

If this isn't what third party cookies do, what are they?

--
--
~kaeli~
Local Area Network in Australia:... the LAN down under.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 20 '05 #13

P: n/a

"Craig" <craig@_netscene.org> wrote in message
news:Ce*******************@news20.bellglobal.com.. .
Hey all,

Here's the situation:

- two websites, one on domain1 and the other on domain2
- domain1 opens a new window which is a javascript app from domain2
- domain1 needs to communicate with the javascript app on domain2

The problem occurs in that last step. Browsers don't allow script access
across domains for security reasons, rightly so. Nonetheless, I still
need to communicate with the application. I can reload the window
passing the necessary commands through the url, but this is slow because
the whole javascript app must reload.

Anyone have any ideas about a way around this limitation that would be
semi-efficient, at least more efficient than reloading the app? Signing
the script isn't an option for cost reasons. I have control over both
sites, so I can do anything that needs to be done.

Regards,
Craig


I know this has already been suggested by the helpful cat loving kaeli (who
has answered one or two PHP posts for me in the past - Happy New Year
kaeli)... but... I *believe* you can use cookies, without breaking security
features in a browser.... though... naturally, if the client has cookies
disabled, my proposed solution below will fail...

When storing a cookie, you can optionally specify the domain name for the
cookie. The security features prevent one domain from *reading* another
domain's cookie - but I believe you can *write* a cookie to a different
domain.

Because I'm a bit of a newbie with cookies, and javascript, I've not got too
involved in to testing this theory, but I've suggested it in this ng more
than once and nobody has ever commented against the suggestion so it might
be worth a try.

Basically, to summerise what I believe can be done is javascript on domain
www.domain1.com can write a cookie, naming the owner as www.domain2.com
Once its written, it is owned by www.domain2.com and it cannot be re-read or
changed later by www.domain1.com

Then... the script on domain2.com just reads the cookie as per normal...

I'm pretty sure I've witnessed something like this before... I was (I think)
on the German Budget website to rent a car and had cookies from
doubleclick.net blocked. The German Budget car rental website failed to
operate properly (no errors, it just failed to respond to alot of menu
options and forms processing). When I permitted doubleclick.net cookies,
everything from the budget.de website began to work as one would expect it.

So... if you're a dab hand at javascript, or someone else reading this is,
then perhaps they could test the above and let me (and the rest of us?) know
if my belief is correct, or more suited to a farmers shovel during spring
time...

An alternative (and again untried) solution would be to have a hidden form
field and use javascript from domain2.com to write to the form that is
hosted on domain1.com

The above is just food for thought, I'd be interested if someone could put
some meat on its bones and give us some feedback...

Cheers
randell d.
Jul 20 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.