[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

Checking Loading Status of Cross-Domain Child Window

Win User

7/24/2014 3:42:00 PM


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

JR

7/24/2014 10:02:00 PM

0

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...
> (yes, not "http://www.google....) 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...
[2] <http://caniuse.com...
[3] <http://en.wikipedia.org/wiki/Single-page_appli...
[4]
<http://www.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-j...

--
Joao Rodrigues

Win User

7/24/2014 10:40:00 PM

0

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


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

Andreas Bergmaier

7/24/2014 11:29:00 PM

0

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

I think you misunderstood the requirements they gave. Citing them:

| *Javascript Test:*
|
| Using http://www.blastam.com/analytics-consu... 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.... 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...." (yes, not "http://www..../")

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

Win User

7/25/2014 12:34:00 AM

0


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/45622...
>
> 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-consu... 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.... 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...." (yes, not "http://www..../")
>
> 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?

Andreas Bergmaier

7/25/2014 2:32:00 AM

0

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

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

Thomas 'PointedEars' Lahn

7/25/2014 10:00:00 AM

0

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-ums...
[2] see e.g. <http://www.webreference.com/xml/column58/inde...
[3] <http://www.w3.org/TR/2000/REC-xhtml1-200...
[4] <https://developer.mozilla.org/en-US/docs/Mozilla/Te...
[5a] <http://www.opera.com/docs/history/presto/...
[5b] <http://blogs.msdn.com/b/ie/archive/2010/11/01/xhtml-in-ie...
[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_docume...
[7] <http://www.w3.org/TR/2008/REC-xml-20081126/#dt...
[8] <http://www.w3.org/TR/2000/REC-xhtml1-20000126/#guid...
[9] <http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/#tex...
[10] <http://www.w3.org/TR/2014/WD-html5-20140617/the-xhtml-syntax.html#the-xhtml-...
--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not Cc: me. / Bitte keine Kopien per E-Mail.