IFRAME cross site access
brosel
-----------
Short descrition:
Trying to read an Element in an self vreated (injected) IFRAME that
loads a site from a different origin.
-----------
Long story:
I try to automate a login to a website.
The script itself (at the moment) works on Page A.
It creates a non hidden IFRAME and sets the "src" Attribute to Page
B1.
Now it should write data (username) to Page B (in the IFRAME) and
submit this page, in order to load Page B2 into the frame (wih a lgged
in user).
Since Page A and Page B(1&2) reside on different servers, this
obviously violates the same origin policy, so its not possible from
within the Javascrip Shell or similar.
But as I understand, this should be no problem for Greasemonkey (it
runs with chrome-privileges, right?).
But I simply dont get it to work :-)
-----------
Question:
So my question can be divided into two:
1. Is this possible?
2 if 1. = true: How?
I played around with this topic for days now and read alot on the net
(and of course searched the forum first), but either I picked the
wrong search terms or I am missing something really #-)
-----------
Possible solution found:
The only thing close to a solution I could find were two scripts, on
sets a kind of mutex from Page A with GM_setValue and the other one
(running on page B) constantly polls the value with GM_getValue and
reacts if it is set. With a little tweaking I should be able to solve
it this way, but I still dont understand, why I get
uncaught exception: Permission denied to get property
HTMLDocument.whateverproperty
error with every approach I tried.
greetings to al Greasemonkey out there,
Brosel
p.s.: "script" always refers to a Greasemonkey User Script in this
mail. There are no "nonGM"-scripts on the Pages A and B.
p.p.s.:Thanks a lot to everyone who could enlighten me. I feel so dumb
right now... (Even telling me it is not possible AND why would be a
great relief to my tormented mind.
Tom Most
> Since Page A and Page B(1&2) reside on different servers, this
> obviously violates the same origin policy, so its not possible from
> within the Javascrip Shell or similar.
> But as I understand, this should be no problem for Greasemonkey (it
> runs with chrome-privileges, right?).
Nope. Greasemonkey scripts run with normal page permissions, aside from
the addition of the GM_* functions. You'll need to write an extension
to sidestep the same-origin policy.
--Tom
Anthony Lieuallen
> brosel wrote:
>> But as I understand, this should be no problem for Greasemonkey (it
>> runs with chrome-privileges, right?).
> Nope. Greasemonkey scripts run with normal page permissions, aside from
> the addition of the GM_* functions. You'll need to write an extension
> to sidestep the same-origin policy.
Or, @include at both pages, and discriminate on document.location for
what to be doing.
brosel
> Or, @include at both pages, and discriminate on document.location for
> what to be doing.
I tried that one, but it seems to me, that the scirpt runs twice (one
when Page A is loaded, and the second time, when Page B in the IFrame
gets loaded), so I couldnt exchange information between the sites or
access functions.
Do you think it would be possible to exchange information (without
polling constantly on GM_getValue) or call a function on site B with
this approach?
Thanks for the answer!
brosel
> Nope. Greasemonkey scripts run with normal page permissions, aside from
> the addition of the GM_* functions.
chrome #-)
> You'll need to write an extension
> to sidestep the same-origin policy.
I am not into extension (so far), but I'll try this.
As I understood, extensions dont get called automatically and there is
a was to make an extension out of a GM-Script.
Now I am looking for best of both worlds, since the user (who
installed the Script/extension) shouldn't have to do anything.
I still don't understand, why a thing like this is not possible in GM,
because I cant see the security issue here .
So my next task probably died an early death (Auto-Login to multiple
sites like GMail, web.de, and gmx and display, for example, all new
mails in one window with custom layout).
Can an extension interact with GM and vice versa?
At the moment, I doubt it very much :-)
again, thanks for the answer. Gave me big relief!
brosel
brosel
Is this really, really always the case? absolutely no workaround,
hack whatsoever?
Csaba Gabor
one, as far as I'm concerned. Specifically,
it is architecturally not very nice for the
"outer" script/page to keep polling for when
the "inner" script/iframe is done. I also
had these concerns a while back and was not a
happy camper:
See this post for a summary:
http://groups.google.com/group/greasemonkey-users/browse_frm/thread/d87f1962ffeb3c94/
Two possible ideas:
Set an event listener for changes on prefs.js
Architecturally, this would seem to be the right
thing, but there are still some issues to solve.
Outline of idea with sample code here:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/edaf805133c1868a/
Maybe this works better in more recent FFs -
Second idea:
Once your inner iframe is ready to hand
back to the parent, it should reload itself
as a data:... or about:blank?... url.
The first part is fine. The real question
is, has the security/cross domain barrier
been neutralized. If so, it will no longer
be inimical to the parent, and so could
kick off a function in the parent. See
https://bugzilla.mozilla.org/show_bug.cgi?id=332182
In fact, I have not yet logged comment 3/4
as a request. Perhaps you should, if you
follow this approach.
The other issue is how does the "outer" script
know which inner script it should be listening
to? That is to say, If you start off your
external (outer) page twice, that means that
you'll have started off two iframe (inner)
pages. How do you ensure there is no cross
signalling? And at the same time keep your
corner of the prefs world clean?
I would very much appreciate hearing back on
where you get with your problem,
Csaba Gabor from Vienna
--- brosel <bro...@spambog.com> wrote:
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
brosel
Great answer, it gives me hope back :-)
I think I'll try the second approach, although I have no idea what you
mean with "reload itself
as a data:... or about:blank?... url. " at the moment, but I'll find
out :-)
I read about the data: url for images (without hitting a central
server). How the about:blank should work is unclear to me.
I like the idea much more than the "right thing" ;-)
And I will have a GMScript on Page B anyway, so this is the lesser
"pain".
Thank you for the hints and the links,
have a good day,
Brosel
Csaba Gabor
>
> Hi Csaba!
> Great answer, it gives me hope back :-)
> I think I'll try the second approach, although I have no idea what you
> mean with "reload itself
Perhaps not reload itself, but rather submit a
form which will change the protocol, in the
hopes that there is not a security issue of
reaching up to the parent with a benign
protocol (such as about:blank).
// previously save data using GM_setValue
document.forms[0].action = intermediatePageString;
document.forms[0].method = "post";
document.forms[0].submit()
intermediatePageString could be of the form:
"javascript:'simple Text'" // shows that text is written
"javascript:alert('Hi mom')" // alert will show
"javascript:'<type=text/javascript>alert('Hi mom')</script>'"
"javascript:top.alert('Hi dad')" // fails appropriately: security
most likely form of success:
"about:blank?GMkey#myDataGoesHere" or a corresponding "data:..." form.
In either situation, you need to have GM key on the appropriate protocol (which I believe it
does for about:blank - at least it does on my version) But in my FF 1.5, this leads to a
security error upon attempt to access top (even though I don't feel it should). According to
the bug report I cited in my prior post (if I understand it right), about:blank should be OK,
about:blank?gunk is not. So you have the issue of getting data to the about:blank page.
Fortunately, your script can place that using GM_setValue and then on entry into about:blank,
you always examine your favorite key to see if your about:blank page is there as a result of
being invoked for the purpose of signaling. Of course, the whole point of this is for the code
in about:blank's GM to reach up to top, which you can test by having the about:blank's portion
of your GM script do something like top.alert('Hi bro') - the point is that it shows you have
access to the parent's DOM.
> as a data:... or about:blank?... url. " at the moment, but I'll find
> out :-)
> I read about the data: url for images (without hitting a central
> server). How the about:blank should work is unclear to me.
just as you include a GM script for http://www.google.com/*
you could do an include for about:blank
Be aware that lots of websites stuff their iframe with about:blank first and set .src later
Don't know if GM keys on the data: protocol.
If it doesn't, submit a bug report - I imagine
they'd add it in, cause they did when I requested
it for about:blank. As always, the issue is
whether you can reach up into the parent from
such a stump page.
> I like the idea much more than the "right thing" ;-)
> And I will have a GMScript on Page B anyway, so this is the lesser
> "pain".
>
> Thank you for the hints and the links,
>
> have a good day,
> Brosel
Csaba Gabor from Vienna
____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/
Tom Most
The typical hack is to pass things between scripts running on the
different domains using GM_setValue, as you yourself suggested. I've
done this; it's a bit of a pain. Frankly, if there is a hack to get
around the same-origin policy without using GM_* functions it should
immediately be filed in Mozilla's Bugzilla as a critical security bug.
Of course, if all you need is to get the contents of the iframe (and you
know its address) you can simply fetch it with GM_xmlhttpRequest.
--Tom
brosel
If I understand you right, the GM_*Value solutions works like this
(just to check, that we are talking about the same thing :-), in this
case getting data from Page A to Page B ):
- Page A loads and gets injected by GM.
- GM Script for Page A inserts the iframe in which Page B is loaded.
- When the user takes apropriate action, Page A sets a
GM_setValue(mykey, my value).
- Page B constantly polls for GM_getValue(mykey, my value).
The problem with GM_xmlhttpRequest was, that i simply couldnt get it
to work. The Page in question uses https (maybe thats a problem?) and
I dont know how to get the cookie it sets.
As you say, it would obiously be a security violation if calling
something from A in B would be possible _without_ using a GM_
function.
What I don't understand is, why such a function doesnt exist.
Something like GM_privilegedDocument(mydocument)
that would return a DOM document with full access (within the GM
sandbox of Page A, of course) and mydocument would be Page B in the
example.
Also a solution on windows (not the MS one:-) ) level should be
possible.
I dont see how this would violate security (still, everything is in
the sandbox).
And I have to trust a downloaded GM script anyhow!
Please correct me, if there is the slightest hint of a fault in
this :-)
greetings,
brosel
brosel
These tips are very helpful, even if it didnt got me close, yet :-)
I tried the about:blank and failed miserably... But that must have
been a bug in my code, because the solution sounds logical and should
work.
And its very, hmm, "intensive", esp. with multiple cross-site Pages
(see above, GMail,gmx, etc.)
I also tried an approach with document.domain an "tld", but it only
works in older (non-fixed) FFs (and so, doesnt really count as a
solution).
But as I dont like polling, your way should be the way ;-)
Do you think it could be possible that the fact that Page B needs
https could be the problem with about:blank?
Either a secuity issue (I read your post and you say somethin about
the right protocoll) or a wrongly manufactured Form (I try it with
using "tamper" now).
I will play aroun some more and let you know.
a nice day,
brosel
p.s.: I found something about signed UserScripts (=chrome privileged);
will read it more carefully, but I think its only for real extensions.
brosel
Thanks for all the responses and hints.
I wanted to check back and tell what I have done know (which is not
very "special")
Firs I tried a few of the conecpt like the about:blank and data-url
hack, I also tried to rebuild the (minimized) form and post it, and
the apporach with pure String-based-xmlhhtprequest.
None of them seemed to work. I cannot tell wheter it was me being to
dumb or just the fact that it was a standard secured login page (with
https, a session cookie with none predictable IDs and a constantly
changing subdomainname).
Finally, we (a friend who knows JS quite good helped me with the
continuation style hacking (because the GM-Script and all its objects
would normally die after the script has finished)) wrote a little
wrapper (to simplyfy things) based on the GM_set/getValue approach
with continuous polling.
We added some additional functionality like a "is Page B already
loaded"-Value (to make sure it doesnt get opened multiple times and a
kind of "smart" polling, so that Page A can show a "please wait" box
and reject every click, until Page B has done its job.
And to appreciate your help, the full story was the following:
There is aweb service in germany called save.tv. They normally charge
quite some money to get an online tv recorder (I also tried the
onlinetvrecorder.com, but the whole downloading process was too
annoying). They also have a free version on free.save.tv.
The idea is, to inject a common EPG (in our case www.tvmovie.com) and
put some funny little icons on this page (Page A). So if I click on
this icon,, the script reads all necessary data (start-stop times,
date and program name) and sends it via the GMValue methods to the
free.save.tv page (Page B). THis Page gets loaded, logs in
automatically and programs the feature.
It works (if the scripts gets out to the world and more people use it
surely not for a long time :-) and some while after the broadcast one
can download it (manually) from their quite fast, purely-commercial
commercial servers (did anyone say "impact on the business
model"? :-)) ).
GM and this project gave me back the fun in hacking after years of
accumulated frustration with Java programming (how they say in the
states? "Swing, Databases, Multithreading, OO-Uno... name it, i've
been there and I don't really want to go back there") Who needs java
anyways (except of business executives, midlifecrised professors and
those darn managers of course)?
No offense to any programmer, in fact I earn my money with Java
hacking, but these projects will give me the compensation I need.
Being creative or trying to battle with source-code-hiss just makes
the difference.
Again, thanks a lot to all helping minds out there!
And sorry for not being able to spare you my religious point of view.
brosel