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

Groups > comp.lang.javascript > #25552 > unrolled thread

Checking Loading Status of Cross-Domain Child Window

Back to article view | Back to comp.lang.javascript

Contents

  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

#25552 — Checking Loading Status of Cross-Domain Child Window

I am being challenged to use only Javascript on a document prepared in XHTML 
Transitional to do several things.  The challenge allows NO modification of 
the XHTML markup.

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 of "http://www.google.com"  
(yes, not "http://www.google.com/") 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.

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.  The 
strategy of just starting a timer of "sufficient duration" and then calling 
the alert with hope that child window content has loaded would not meet the 
challenge.

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.

Is there/are there solutions?

[toc] | [next] | [standalone]

#25557

On 24/07/2014 12:42, Win User wrote:
> I am being challenged to use only Javascript on a document prepared in XHTML
> Transitional

Firstly, I'd suggest to not waste your time writing XHTML documents, 
because web browsers have historically rendered XHMTL documents with a 
MIME type of text/html, no matter the 'application/xhtml+xml' MIME type 
was supplied, or the document started with the XHTML doctype [1].

Nowadays, it seems that the major browsers truly support XHTML, only if 
the 'application/xhtml+xml' MIME type is supplied by the web server [2].

Therefore, if you write XHTML documents, you still need to serve HTML to 
the old browsers that don't understand "application/xhtml+xml", which 
increases the complexity of your application. For instance, you'd need a 
server-side script to test what MIME types the browser requesting your 
webpage supports, in order to set up a correct document.

> to do several things.  The challenge allows NO modification of
> the XHTML markup.
>
> 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 of "http://www.google.com"
> (yes, not "http://www.google.com/") 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.
>
> 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.  The
> strategy of just starting a timer of "sufficient duration" and then calling
> the alert with hope that child window content has loaded would not meet the
> challenge.
>
> 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.
>
> Is there/are there solutions?

I understood that you need to implement a "single-page application" [3]. 
If so, then you may use a JavaScript framework such as Angular.js, 
Backbone.js, Ember.js, KnockoutJS, JavascriptMVC, etc. There is a good 
article by Addy Osmani comparing the alternatives [4].

[1] <https://developer.mozilla.org/en-US/docs/Glossary/XHTML>
[2] <http://caniuse.com/xhtml>
[3] <http://en.wikipedia.org/wiki/Single-page_application>
[4] 
<http://www.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/>

-- 
Joao Rodrigues

[toc] | [prev] | [next] | [standalone]

#25558

Joao Rodrigues <groups_jr-1@yahoo.com.br> wrote on Thu 24 Jul 2014
03:02:09p 

> On 24/07/2014 12:42, Win User wrote:
>> I am being challenged to use only Javascript on a document prepared in
>> XHTML Transitional
> 
> Firstly, I'd suggest to not waste your time writing XHTML documents, 
> because web browsers have historically rendered XHMTL documents with a 
> MIME type of text/html, no matter the 'application/xhtml+xml' MIME type 
> was supplied, or the document started with the XHTML doctype [1].

I perfectly agree.  But 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

 
> Nowadays, it seems that the major browsers truly support XHTML, only if 
> the 'application/xhtml+xml' MIME type is supplied by the web server [2].
 
> Therefore, if you write XHTML documents, you still need to serve HTML to
> the old browsers that don't understand "application/xhtml+xml", which 
> increases the complexity of your application. For instance, you'd need a
> server-side script to test what MIME types the browser requesting your 
> webpage supports, in order to set up a correct document.
> 
>> to do several things.  The challenge allows NO modification of
>> the XHTML markup.
>>
>> 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 of
>> "http://www.google.com" (yes, not "http://www.google.com/") 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.
>>
>> 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.  The strategy of just starting a timer of
>> "sufficient duration" and then calling the alert with hope that child
>> window content has loaded would not meet the challenge.
>>
>> 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.
>>
>> Is there/are there solutions?
> 
> I understood that you need to implement a "single-page application" [3].

This might contain a solution.

Having shown you the challenge however, this should be done without having 
to make use of frameworks or libraries, I would think.

If I were the employer looking for that "Javascript expert," do I want 
someone who tells me he can use an "API" (set up call with parameters) to a 
Javascript library/blackbox, or do I want someone who actually knows how to 
write the library code itself, especially if it amounts to using a few lines 
from that library code?

[toc] | [prev] | [next] | [standalone]

#25559

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:

| *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. Just fire an alert when the link was clicked, you 
don't need to wait for the window to load.

> 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.

> 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.

Kind regards,
  Bergi

[toc] | [prev] | [next] | [standalone]

#25560

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?

[toc] | [prev] | [next] | [standalone]

#25561

Win User schrieb:

> 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.

Even the fact *that* it has been loaded would be a privacy issue and 
might help to execute attacks on the foreign domain. Also, the timing 
information could give you knowledge about whether the requested 
ressource(s) have been in the cache, i.e. been visited previously.
If you search for "timing attacks" you might understand how useful such 
information can be (even if most of it is about crypto algorithms, there 
have been timing attacks on the web 
<http://www.contextis.com/documents/2/Browser_Timing_Attacks.pdf>).

> Apparently there are solutions when using HTML5 in one document from another
> domain in "messaging" another,

All these communication techniques are based on explicit, mutual 
agreement in both documents. Google will hardly accept any messages that 
you send to their homepage document.

 > and even in peering into content (using content in the form of JSONP
 > and using proxy servers, no matter what DOCTYPE).

Those are not needed to be protected by the SOP. The point is that these 
are not using the user's credentials to request the ressources, but 
simple access freely available data on the web.

[toc] | [prev] | [next] | [standalone]

#25562

Joao Rodrigues wrote:

> On 24/07/2014 12:42, Win User wrote:
>> I am being challenged to use only Javascript on a document prepared in
>> XHTML Transitional
> 
> Firstly, I'd suggest to not waste your time writing XHTML documents,
> because web browsers have historically rendered XHMTL documents with a
> MIME type of text/html, no matter the 'application/xhtml+xml' MIME type
> was supplied, or the document started with the XHTML doctype [1].

Utter nonsense.  In fact, documents that have been served with a “Content-
Type: text/html …” header field have been rendered as erroneous (and 
therefore error-corrected) HTML no matter the DOCTYPE declaration.

Documents that have been served with “Content-Type: application/xhtml+xml …” 
(and compatible MIME media types) have either not been rendered at all 
(e.g., by IE/MSHTML 6.0 which displayed a download dialog instead) or they 
have been rendered as XHTML. [1]

> Nowadays, it seems that the major browsers truly support XHTML, only if
> the 'application/xhtml+xml' MIME type is supplied by the web server [2]

Netscape NGLayout/Mozilla Gecko was able to render XHTML documents served 
with “Content-Type: application/xhtml+xml …” as XHTML since its first 
version, released in 2001 [2] (XHTML became a W3C Recommendation in 2000 
[3]).  That was because Mozilla, the Netscape Communicator rewrite, already 
included an XML parser, using XUL for its chrome; XUL is still used by 
Mozilla-based products today [4].

Other layout engines, like Opera’s Elektra and Presto [5a], followed.  
MSHTML was the exception until before Internet Explorer/MSHTML 9.0. [5b]

Rendering a document as XHTML meant and means that an XML parser is used, 
and syntax errors that violate XML well-formedness cause a document not to 
be displayed; the error message is displayed instead [6][7].

> Therefore, if you write XHTML documents, you still need to serve HTML to
> the old browsers that don't understand "application/xhtml+xml",

Nonsense.  They can serve “HTML-compatible” XHTML documents with “Content-
Type: text/html”, forfeiting the advantages that XHTML has to offer on the 
client side.

People, sometimes misguided, did and do it all the time, partially based on 
“HTML-compatible XHTML” explained in XHTML 1.0 Appendix C [8], which was 
superseded by a Working Group Note [9].  Apparently the authors of parsers 
and layout engines have learned to deal with that, and whose who did not are 
obsolete.

Finally, HTML5, “A vocabulary and associated APIs for HTML and XHTML”, 
specifies an “XHTML syntax” for “XML resources” not served with “Content-
Type: text/html …”. [10]

_________
[1] [de] <http://dciwam.de/faq/xhtml/wann-auf-xhtml-umsteigen>
[2] see e.g. <http://www.webreference.com/xml/column58/index.html>
[3] <http://www.w3.org/TR/2000/REC-xhtml1-20000126/>
[4] <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL>
[5a] <http://www.opera.com/docs/history/presto/#facts>
[5b] <http://blogs.msdn.com/b/ie/archive/2010/11/01/xhtml-in-ie9.aspx>
[6] <https://developer.mozilla.org/en-US/docs/Mozilla_Web_Developer_FAQ#How_is_the_treatment_of_application.2Fxhtml.2Bxml_documents_different_from_the_treatment_of_text.2Fhtml_documents.3F>
[7] <http://www.w3.org/TR/2008/REC-xml-20081126/#dt-error>
[8] <http://www.w3.org/TR/2000/REC-xhtml1-20000126/#guidelines>
[9] <http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/#text-html>
[10] <http://www.w3.org/TR/2014/WD-html5-20140617/the-xhtml-syntax.html#the-xhtml-syntax>
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web