468,545 Members | 1,782 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,545 developers. It's quick & easy.

Cross Domain Scripting with Friendly Domains

Having read the CLJ FAQ and having done extensive Googling, I do
understand that in in general cross-domain iframe scripting is not
permitted. One issue I have not seen directly addressed, however, is
scripting across different but still "friendly" domains.

Essentially I'd like to send a signal from the child to the parent in
any form at all. I would think that there might exist a way to set some
variable or object property that could both be read by the parent and
written to by the child (or vice versa).

Am I just totally wrong?
Thanks,
Jacob.

Aug 11 '06 #1
4 1942
Jacob JKW said the following on 8/10/2006 8:27 PM:
Having read the CLJ FAQ and having done extensive Googling, I do
understand that in in general cross-domain iframe scripting is not
permitted. One issue I have not seen directly addressed, however, is
scripting across different but still "friendly" domains.
Yes, and those "friendly" domains are in your "Trusted Sites" list in IE.
Essentially I'd like to send a signal from the child to the parent in
any form at all. I would think that there might exist a way to set some
variable or object property that could both be read by the parent and
written to by the child (or vice versa).
Check into the Trusted Sites. That's for your browser. If you are
hunting some way to send a "signal" from two different domains in a
user's browser, give it up.
Am I just totally wrong?
That depends on what you think and what you are trying to do.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Aug 11 '06 #2

"Jacob JKW" <ja******@yahoo.comwrote in message
news:11*********************@75g2000cwc.googlegrou ps.com...
Having read the CLJ FAQ and having done extensive Googling, I do
understand that in in general cross-domain iframe scripting is not
permitted. One issue I have not seen directly addressed, however, is
scripting across different but still "friendly" domains.

Essentially I'd like to send a signal from the child to the parent in
any form at all. I would think that there might exist a way to set some
variable or object property that could both be read by the parent and
written to by the child (or vice versa).

Am I just totally wrong?
I've often thought there _should_ be a system for this - some extension the
browser object model that provided for a "public" scope which which you
could store information visible to anybody. But there isn't.

I once played extensively with this. The most successful failure I had
dealt with setting asynchronous messages in the status bar in one frame and
reading them in another. It worked, mostly, but not in all browsers (if I
remember correctly at the time it worked in IE 4, 5 and 6 on Windows and
Mozilla... but oddly enough not on IE 5.5 - or something like that).

Even if it did work across all browsers it would almost definately have been
seen as a security bug and fixed to eliminate the (already very tenuous)
connection.

One thing you can do is consume script from another site. Although the
script itself is then considered "local" (it's run with the same privledges
as if it were loaded from the containing page's server) it can, of course,
contain "special" information from the other server.

We use this, as an example, in a site were the "main site" frames some
information from an affiliated site. The main site has left-hand navigation
and a bread-crumb trail that the affiliated site needs to mimic. So we've
encapsulated all of the code for those into a JS file: both sites call the
same file and can display any state of the navigation. The main site passed
query-string parameters to the affiliate site when it's called to let it
know the state of the navigation so that the two match.

Although in reality there are two sets of navigation (one per site) it
_looks_ like one set, one site, and we only have to maintain one file with
the information.

If you set cookie or query-string variables on the call to the script itself
you can pass information to the other server (although this would have to be
dealt with by a server-side component, not client-side javascript which
wouldn't have access). But simple server-side script could inteperate the
information and dynamically generate the client-side script (this is, in
fact, what's done by many banner-ad aggregators).

An image call (for example) could also be used to send such information to
another server.

The server would stow the information someplace which could be retrieved by
the client-side script in the other frame. In this way (badly explained I
know) the two sets of client-side scripts, separated on the client-side,
could use a server-side conduit to "talk". It's ugly and slow and messy but
it would work.

But as far as real client-side communication... I doubt you'll see one.
Even if you do find a hack don't expect it to stay available. ;^)

Jim Davis
Aug 13 '06 #3

Jim Davis wrote:
"Jacob JKW" <ja******@yahoo.comwrote in message
news:11*********************@75g2000cwc.googlegrou ps.com...
Having read the CLJ FAQ and having done extensive Googling, I do
understand that in in general cross-domain iframe scripting is not
permitted. One issue I have not seen directly addressed, however, is
scripting across different but still "friendly" domains.

Essentially I'd like to send a signal from the child to the parent in
any form at all. I would think that there might exist a way to set some
variable or object property that could both be read by the parent and
written to by the child (or vice versa).

Am I just totally wrong?

I've often thought there _should_ be a system for this - some extension the
browser object model that provided for a "public" scope which which you
could store information visible to anybody. But there isn't.

Even if it did work across all browsers it would almost definately have been
seen as a security bug and fixed to eliminate the (already very tenuous)
connection.

One thing you can do is consume script from another site. Although the
script itself is then considered "local" (it's run with the same privledges
as if it were loaded from the containing page's server) it can, of course,
contain "special" information from the other server.
I actually just found this site:
http://eng.professionalconsulting.ru/lab/ajaxextended/ and thought it
extremely cool.

Aug 13 '06 #4


Jacob JKW wrote:
Having read the CLJ FAQ and having done extensive Googling, I do
understand that in in general cross-domain iframe scripting is not
permitted. One issue I have not seen directly addressed, however, is
scripting across different but still "friendly" domains.

Essentially I'd like to send a signal from the child to the parent in
any form at all. I would think that there might exist a way to set some
variable or object property that could both be read by the parent and
written to by the child (or vice versa).
Opera 8 and 9 has support for this API
<http://www.whatwg.org/specs/web-apps/current-work/#crossDocumentMessages>
here is a simple example
<http://home.arcor.de/martin.honnen/javascript/2006/08/test2006081301.html>
using that API to send a message with script in a document on
home.arcor.de to the document in the iframe which sits on
www34.brinkster.com.

The upcoming Firefox 2.0 will support this API
<http://www.whatwg.org/specs/web-apps/current-work/#scs-client-side>
that exposes a global storage based on domain parts.
Of course none of that currently helps far on the web if you expect
visitors with all sorts of browsers.
--

Martin Honnen
http://JavaScript.FAQTs.com/
Aug 13 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Angus SC2 | last post: by
6 posts views Thread by Charles Crume | last post: by
6 posts views Thread by Bart Van der Donck | last post: by
16 posts views Thread by Stevo | last post: by
6 posts views Thread by ampo | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.