Communicating via javascript across domains

C

Craig

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
 
B

Brian Genisio

Craig said:
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/author/hta/hta_node_entry.asp

Brian
 
K

kaeli

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.


--
 
D

Douglas Crockford

- 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/
 
P

Patricio Stegmann

Le Wed, 04 Feb 2004 11:47:58 -0600, kaeli a écrit :
Cookies.
Not the best, but better than nothing.


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

Craig

Douglas said:
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.
 
C

Craig

Patricio said:
Le Wed, 04 Feb 2004 11:47:58 -0600, kaeli a écrit :



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

Craig

Brian said:
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/author/hta/hta_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
 
D

Douglas Crockford

- two websites, one on domain1 and the other on domain2
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/
 
G

grp_pst_363

Craig said:
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.location.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.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
 
G

grp_pst_363

Craig said:
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
 
C

Craig

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
 
K

kaeli

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?

--
 
R

Reply Via Newsgroup Thanks

Craig said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,764
Messages
2,569,566
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top