views:

1224

answers:

8

So I have two documents dA and dB hosted on two different servers sA and sB respectively.

Document dA has some JS which opens up an iframe src'ing document dB, with a form on it. when the form in document dB is submitted to a form-handler on server sB, I want the iframe on page dA to close.

I hope that was clear enough. Is there a way to do this?

Thanks!

-Mala

UPDATE: I have no control over dA or sA except via inserted javascript

+3  A: 

This isn't supposed to be possible due to browser/JavaScript security sandbox policy. That being said, it is possible to step outside of those limitations with a bit of hackery. There are a variety of methods, some involving Flash.

I would recommend against doing this if possible, but if you must, I'd recommend the DNS approach referred to here:

http://www.alexpooley.com/2007/08/07/how-to-cross-domain-javascript/

Key Excerpt:

Say domain D wants to connect to domain E. In a nutshell, the trick is to use DNS to point a sub-domain of D, D_s, to E’s server. In doing so, D_s takes on the characteristics of E, while also being accessible to D.

Mark Hammonds
A: 

A mechanism to do so would be capable of a cross-site scripting attack (since you could do more than just remove a benign bit of page content).

A safe approach would limit to just the iframe document emptying/hiding itself, but if the iframe containing it is fixed size, you will just end up with a blank spot on the page.

Steve Gilham
How could I make an iframe size itself vertically dependant on the content of the frame? This would solve my problem in that I could just have the iframe show an empty page to "remove" it
Mala
A: 

If you don't have control over dA or Sa this isn't possible because of browser security restrictions. Even the Flash methods require access to both servers.

Mark Hammonds
+1  A: 

Assume that I create page A, that lies withing a frame that covers the entire page. Let A link to yourbank.com, and you click on that link. Now if I could use javascript that modifies the content of the frame (banking site), I would be able to quite easily read the password you are using and store it in a cookie, send it to my server, etc.

That is the reason you cannot modify the content in another frame, whose content is NOT from the same domain. However, if they ARE from the same domain, you should be able to modify it as you see fit (both pages must be on your server).

You should be able to access the iframe with this code:

window["iframe_name"].document.body
Paxinum
+2  A: 
Eugene Lazutkin
Just incredible. I've never heard of that technique. With Chrome and Safari, you can even pass the plain top-level domain to the setter...
Pumbaa80
+2  A: 

If you just want the top-level to close, you can just call something like this:

window.top.location = "http://www.example.com/dC.html";

This will close out dA and sent the user to dC.html instead. dC.html can have the JS you want to run (for example, to close the window) in the onload handler.

MiffTheFox
A: 

This is a bit convoluted but may be more legitimate than a straight XSS solution:

You have no control over server A other than writing javascript to document A. But you are opening an iframe within document A, which suggests that you only have write-access to document A. This a bit confusing. Are you writing the js to document A or injecting it somehow?

Either way, here is what I dreamed up. It won't work if you have no access to the server which hosts the page which has the iframe.

The user hits submit on the form within the iframe. The form, once completed, most likely changes something on the server hosting that form. So you have an AJAX function on Document A which asks a server-side script to check if the form has been submitted yet. If it has, the script returns a "submitted" value to the AJAX function, which triggers another js function to close the iframe.

The above requires a few things:

  • The iframe needs to be on a page hosted on a server where you can write an additional server-side script (this avoids the cross-domain issue, since the AJAX is pointing to the same directory, in theory).

  • The server within the iframe must have some url that can be requested which will return some kind of confirmation that the form has been submitted.

  • The "check-for-submitted" script needs to know both the above-mentioned URL and what to look for upon loading said URL.

If you have all of the above, the ajax function calls the server-script, the server-script uses cURL to go the URL that reflects if the form is done, the server-script looks for the "form has been submitted" indicators, and, depending on what it finds, returns an answer of "not submitted" or "submitted" to the ajax function.

For example, maybe the form is for user registration. If your outer document knows what username will be entered into the form, the server-side script can go to http://example.org/username and if it comes up with "user not found" you know the form has yet to be submitted.

Anything that goes beyond what is possible in the above example is probably outside of what is safe and secure anyway. While it would be very convenient to have the iframe close automatically when the user has submitted it, consider the possibility that I have sent you an email saying your bank account needs looking at. The email has a link to a page I have made which has an iframe of your bank's site set to fill the entire viewable part of my page. You log in as normal, because you are very trusting. If I had access to the fact that you hit submit on the page, that would imply I also had access to what you submitted or at the very least the URL that the iframe redirected to (which could have a session ID in or all sorts of other data the bank shouldn't include in a URL).

I don't mean to sound preachy at all. You should just consider that in order to know about one event, you often are given access to other data that you ought not have.

I think a slightly less elegant solution to your problem would be to have a link above the iframe that says "Finished" or "Close" that kills the iframe when the user is done with the form. This would not only close the iframe when the user has submitted the form, but also give them a chance to to say "oops! I don't want to fill out this form anyway. Nevermind!" Right now with your desired automatic solution, there is no way to get rid of the iframe unless the user hits submit.

Anthony
A: 

Thank you everybody for your answers. I found a solution that works:

On my server, I tell the form to redirect to the url that created the iframe. On the site containing the iframe, I add a setInterval function to poll for the current location of the iframe.

Due to JS sandboxing, this poll does not work while the url is foreign (i.e. before my form is submitted). However, once the url is local (i.e. identical to that of the calling page), the url is readable, and the function closes the iframe. This works as soon as the iframe is redirected, I don't even need to wait for the additional pageload.

Thank you very much Greg for helping me :)

Mala