incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: [DISCUSS] window.open target blank
Date Tue, 07 Aug 2012 23:30:25 GMT
Brion:
Yes, this should be considered part of the API, the 'how' is yet to be
defined, but apps need the ability to specifically target both the default
system browser AND the ChildBrowser.

===

Re: My Proposal, ( I have officially flipped ... )

After writing/sending my proposal, I thought back to the origins of the
ChildBrowser plugin.  Back when Shaz and I wrote it some 2+ years ago, the
goal was to allow non-secure content to be loaded into the application
without offering any chance of the app/dom being hijacked.  At the time,
there was no whitelist, and all was fine.

Now that we have a whitelist, I think we need to re-evaluate it's purpose.
 IMHO the ChildBrowser should NOT be restricted to domains in the
whitelist.  If you imagine attempting to develop a twitter clone, it would
be impossible to display links in tweets unless you either, jumped out to
the system browser, or had an allow * in the whitelist.  IMO this is a
perfectly valid use case for building a phonegap app.

Displaying content from ANY domain should be a perfectly acceptable
practice.
Running JS code inside the ChildBrowser from ANY domain should be
acceptable as well. ( XHR cross-domain requests should continue to be
governed by the security already present in the browser control itself )
Mixing code/content from the internet domain with the app domain SHOULD be
governed by the whitelist.

The ChildBrowser already shields the app from unsafe internet code, in that
it does NOT allow any of the APIs that phonegap does.  This is in harmony
with the initial intent of the plugin, to safely display some content ...
and not lose the app context.

My adjusted proposal follows :

1. The security/whitelist checking should be adjusted to only apply to
access attempts by the CDVViewController, and not the entire application. (
not easy, I know Shaz, I can help )
2. If ChildBrowser is present, it should include code to intercept
target._blank and polyfil window.open to its own API. (JS POC needed)
3. ChildBrowser should get an additional API to specifically target
the system default browser. ( API details TBD )

Cheers,
  Jesse




On Mon, Aug 6, 2012 at 4:55 PM, Brion Vibber <brion@pobox.com> wrote:

> On Mon, Aug 6, 2012 at 3:52 PM, Jesse MacFadyen <purplecabbage@gmail.com
> >wrote:
>
> > [PROPOSAL]
> >
> > 1. If a URL is not in the whitelist, it will be passed to the default
> > system browser regardless of any other rule. ( this will be handled on
> > the native side, by the framework and the JS side may not even know it
> > has happened. )
> >
>
> If the URL *is* in the whitelist, can we send it to the default system
> browser too when calling window.open?
>
> For lots of our usage at Wikimedia, we need to whitelist Wikipedia sites in
> order to do API calls via XHR (at least on iOS), but also want to be able
> to open specific pages in the system browser.
>
> 2. If ChildBrowser is present, it should include code to intercept
> > target._blank and polyfil window.open to its own API.
> > 3. ChildBrowser should get an additional API to specifically target
> > the system default browser.
> >
>
> -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
>



-- 
@purplecabbage
risingj.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message