Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #25560

Re: Checking Loading Status of Cross-Domain Child Window

Show all headers | View raw

Andreas Bergmaier <andber93@web.de> wrote:

> Win User schrieb:
> 
>> this is part of a job application process, in which
>> the employer is challenges applicants to make changes using only
>> Javascript (no changes to markup), and then appears to want to know how
>> the applicant handles a cross-domain child window problem.  See for
>> yourself:  the challenge is at the bottom of the page:
>>
>>      http://sacramento.craigslist.org/sof/4562251797.html
> 
> I think you misunderstood the requirements they gave. Citing them:

Yes, it is possible I read too much into the instructions, especially since 
I ran into what would be an impossibility for someone who is in the very 
ordinary Javascript coder class.

> 
>| *Javascript Test:*
>|
>| Using http://www.blastam.com/analytics-consulting.aspx as your source 
>| page, write javascript that would accomplish the following:
>| * Hide the Print | Email | Share div in the right column of the page.
>| * Change the Blast AM logo at the top left to:
>|   1) Link to http://www.google.com instead of /.
>|   2) Have it open in a new window when clicked.
>|   3) Fire an alert dialog that says the following when clicked:
>|      Please Hire Me!
>| * Change the 'Consulting By Platform' H3 element to all uppercase.
>|
>| […]
>| We will test by executing your script in console on the URL above, so
>| we recommend you test your script the same way. It is probably
>| easiest to write your JavaScript in console as well versus attempting
>| to setup a local or hosted copy of our page.
> 
>> There is only one thing I have NOT been able to figure out.  I am
>> required to open a child window and load it with the content
> 
> Not exaclty. You don't have to open it by JS, you just need make the 
> link open in a new window. (using the target attribute, probably)
> 
>> "http://www.google.com" (yes, not "http://www.google.com/")
> 
> No. They just want you to change the link, which is currently "/" 
> (inspect the page they gave!), to the google site. It's quite impossible
> to prevent Google from redirecting you to where they want once you've 
> entered their URL.
> 
> > and then I am supposed to call an alert.
>>
>> It seems logical to write client code that determines the completion of
>> the loading status of the child window.
> 
> I don't think so.

Now while I perfectly understand script executed from a document from one 
domain not being at all able to read from and write to content of a document 
(loading or loaded) from another domain, I don't see the security flaw in 
one document opening a child window and getting a signal "the document is 
loaded" event.  Perhaps someone can tell me why a "child window content 
loaded" signal--with no ability to know the content of it---would be of 
great interest to the malevolent hacker.

> Just fire an alert when the link was clicked, you 
> don't need to wait for the window to load.

Yes, especially since the alert won't appear in front of the child 
window/tab.

>> My search of the network shows code setting up time interval for
>> polling the document's readyState property as "complete."  But that
>> only works on same- origin (same domain) content.  Cross-domain
>> attempts trigger an error.
> 
> Yes, that's enforced by the same-origin-policy, and that's good.

Again, why is that "good"?  I just want to know whether the child window 
content loaded, not rummage around inside it.

>> And then there's the problem of opening an alert in front the child
>> window: if 'childWin' is the window object, the call childWin.alert()
>> triggers an error.
> 
> I don't think you're supposed to open the the alert in the child window.
> If you have problems with the child window opening in front of you, just
> re-focus the parent page. Search for "pop-under" for various techniques 
> to achieve that, especially in the presence of a popup blocker.
> 
>> Is there/are there solutions?
> 
> No. If you could open an alert on google's homepage, that would 
> seriously pervert the same-origin-policy and be a large security issue. 
> Of course, that employeer being an analytics enterprise they would 
> probably be glad if you were a hacker that can find holes in the SOP. 
> However, this is not what this trivial "test" is about.

Apparently there are solutions when using HTML5 in one document from another 
domain in "messaging" another, and even in peering into content  (using 
content in the form of JSONP and using proxy servers, no matter what 
DOCTYPE).  I rather wonder if that is the job application test answer...to 
be so "expert" as to its implementations so as to exploit its/their 
vulnerabilities?

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Checking Loading Status of Cross-Domain Child Window Win User <winuser@ms.invalid> - 2014-07-24 15:42 +0000
  Re: Checking Loading Status of Cross-Domain Child Window Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-07-24 19:02 -0300
    Re: Checking Loading Status of Cross-Domain Child Window Win User <winuser@ms.invalid> - 2014-07-24 22:40 +0000
      Re: Checking Loading Status of Cross-Domain Child Window Andreas Bergmaier <andber93@web.de> - 2014-07-25 01:28 +0200
        Re: Checking Loading Status of Cross-Domain Child Window Win User <winuser@ms.invalid> - 2014-07-25 00:34 +0000
          Re: Checking Loading Status of Cross-Domain Child Window Andreas Bergmaier <andber93@web.de> - 2014-07-25 04:31 +0200
    Re: Checking Loading Status of Cross-Domain Child Window Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-25 11:59 +0200

csiph-web