1

Okay, this is similar, but not the same, to the 'How to detect when iframe src changes' question, because it is when the iframe wants to change. What I mean is, I have an iframe with Google in it (I just started working on a web-based OS because I was bored, check http://dextive.com/russellsayshi/os/ ) but the problem is google uses a header to block being displayed in iframes.

The way I got around it so far is by making a PHP page with this simple source (please forgive my PHP noobness):

<?php
echo "<base href='".$_GET['url']."'>";

$site=file_get_contents($_GET['url']);

echo $site;
?>

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.8.1/jquery.min.js"></script>
<script type="text/javascript">
$("a").click(function() {
    var href = this.href;
    var baseURL = "overridexframe.php?url=";
    window.location = baseURL + href;
    return false;
});
</script>

This works great, and having the iframe source set to overridexframe.php?url=(url goes here) works great, until you try a search. As you can see above, I have jQuery fixing links, but when it tries to change it using javascript, it is not going to my specified override URI. Does anyone know a way to try and catch when an iframe tries to change, but can’t, so I can apply JS to it?

AstroCB
  • 12,337
  • 20
  • 57
  • 73
russellsayshi
  • 2,449
  • 5
  • 17
  • 21
  • cant really comment on the JS, but you should protect you GET references, at least make sure you are escaping the values -its a potential security hole. Not trying to spark a "which escaping procedure is the best" discussion, something like stripslashes($_GET['url']) is better than nothing. – Nick Sep 27 '12 at 23:45
  • this page might help out with escaping your GET values: http://stackoverflow.com/questions/1522313/php-mysql-real-escape-string-stripslashes-leaving-multiple-slashes – Nick Sep 27 '12 at 23:49
  • don't frame pages that don't want to be framed. –  Sep 28 '12 at 00:52

2 Answers2

0

No, there is no official way of detecting when a frame is to request a new URL using only JavaScript - as there would probably be quite a few secutiry ramifications if you could. The only way to achieve this (and be able to workout where the frame is going) is to step in before each possible way a user could navigate elsewhere. There are many ways to cause a page to navigate to another location:

  1. clicking a link
  2. submitting a form
  3. typing in the address bar
  4. javascript / plugins triggering window.location
  5. meta refresh tag
  6. javascript / plugins requesting window.open using target as _self or _top

Only some of the above are "overridable", and even then it's not wholly reliable... which is why I would advise you not to carry on in the fashion you are - unless this project is only ever for learning or fun. Grabbing another site's source and outputting it inside your own will cause you all sorts of coding problems... not to mention the legal ramifications with regards to copyright and terms of use.

Anyway, in the spirit of answering your question you could probably fix the "search" problem with google by creating not only a link override, but also a form submit override with the following:

$('form').submit(function(){

    var form = $(this);

    /// this code will allow you to hijack any forms that try to submit
    /// and stop them submitting, whilst at the same time allowing you
    /// to do something else instead.

    return false;
});

The problem with the above however is that you will have to code javascript that will convert the form that is being submitted into a simple GET Url that you can append to your override path. This is doable if the form is designed to simply send it's information via GET (luckily Google does this). This is discussed in the link below (look for the jQuery form.serializeArray comment, just instead of AJAX you can use this to generate your URL):

How to convert simple form submit to ajax call;

How to build query string with Javascript

However if the form POSTs it's data instead, the method you are using is not going to work without a whole heap of rather complicated unreliable stuff being implemented... If you think about it, what URL do you use to represent a POSTed form with all it's data? -- yep, exactly the same URL as the form without data.

Put simply, I'd think of a different way of doing what you want if you wish to expand this system to cover more pages than a screenscrape of Google.

Community
  • 1
  • 1
Pebbl
  • 34,937
  • 6
  • 62
  • 64
  • Okay thanks, do you have any suggestions on how to do it differently? Also, thanks for the answer. – russellsayshi Sep 28 '12 at 23:35
  • What you're attempting to do is something you can't really do - esp. not in pure JS & HTML. Other 'online operating systems' generally either rely on a 3rd-party plugin or downloadable environment to work - for precisely the reasons you're encountering. Or if they are only in-browser they wont tend to provide a browser... considering the user already has one in order to visit the "OS". Basically you've no way around totally embedding another site inside yours *(Google has terms directly against this)* unless that site owner allows you to or you use something like Flash/Java/Silverlight... – Pebbl Sep 29 '12 at 11:46
0

What exactly are you trying to achieve here? I see a pop up "browser" in your "OS".. IF you want to take control of the pages that you are showing in your browser popup (Which I assume is where the offending iFrame is) have you considered using your server side scripting language (PHP maybe) to deal with the iFrame?

Assuming PHP, it could work like this:

use cURL or file_get_contents() to get the page you want to show. the page is now in PHP do a find/replace to manipulate all href values and change your urls to something like this:

href="local_handler.php?target=orig_url"

do this also for any form targets you might find. Your "local_handler.php" script then deal with all the logging.

The upshot of this is you can now totally loose the iFrame. The external sites code is now within your original window - you might have some styling issues and maybe some conflicting JS issues.

Nick
  • 908
  • 12
  • 29