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 Thu, 09 Aug 2012 18:33:17 GMT
Can we get more than an hour?

On Thu, Aug 9, 2012 at 11:24 AM, Brian LeRoux <b@brian.io> wrote:

> So---is this solid enough ground to open some issues / make this a part of
> 2.1?
>
> (end of september)
>
>
>
>
> On Thu, Aug 9, 2012 at 10:59 AM, Michael Brooks
> <michael@michaelbrooks.ca> wrote:
> > Nice Dave, those conditions make sense to me.
> >
> > On Thu, Aug 9, 2012 at 10:54 AM, Dave Johnson <dave.c.johnson@gmail.com
> >wrote:
> >
> >> These are the window.open calls that we need to consider:
> >>
> >> 1) window.open('local-url.html', '_self');                     //
> >> loads in CordovaView. _parent and _top same thing
> >> 2) window.open('local-url.html', '_blank');                   // loads
> >> in InAppBrowser
> >> 3) window.open('http://whitelisted-url.com', '_self');    // loads in
> >> CordovaView
> >> 4) window.open('http://whitelisted-url.com', '_blank');  // loads in
> >> InAppBrowser
> >> 5) window.open('http://random-url.com', '_self');         // loads in
> >> InAppBrowser
> >> 6) window.open('http://random-url.com', '_blank');      // native
> browser
> >>
> >> window.location = 'foo' is equivalent to the '_self' options above.
> >>
> >> I'm operating under the assumption that local and whitelisted URLs
> >> should be opened with Cordova functionality by default (_self) and you
> >> have to be explicit if you want those trusted resources opened without
> >> Cordova functionality (_blank).
> >>
> >>
> >> On Wed, Aug 8, 2012 at 12:13 PM, Brian LeRoux <b@brian.io> wrote:
> >> > I'd rather we continue to encourage single page apps as the best
> >> > practice for building apps w/ html, css, and js. The many views
> >> > architecture seems like it would create a strong coupling to the
> >> > native side (for transitioning esp so).
> >> >
> >> > I view the cleaver-ing as creating a transition path for native apps
> >> > to cordova apps and/or allowing the facebook/linkedin/twitter webview
> >> > with native chrome use case (which I do not love but understand the
> >> > desire for it in some cases).
> >> >
> >> >
> >> > On Wed, Aug 8, 2012 at 11:55 AM, Jesse MacFadyen
> >> > <purplecabbage@gmail.com> wrote:
> >> >> In the future we may want to allow multi-view apps, as this was part
> >> >> of the reasoning for cleaving the view...
> >> >> does this change anything?
> >> >>
> >> >> Cheers,
> >> >>   Jesse
> >> >>
> >> >> Sent from my iPhone
> >> >>
> >> >> On 2012-08-08, at 11:28 AM, Brian LeRoux <b@brian.io> wrote:
> >> >>
> >> >>> Meant to reply to this. I think Mike is correct:
> >> >>>
> >> >>> _blank === system browser
> >> >>> _self === child browser
> >> >>>
> >> >>> Thoughts?
> >> >>>
> >> >>>
> >> >>> * * *
> >> >>>
> >> >>> ChildBrowser === InAppBrowser <---not perfect but it gets rid
of
> >> pedobear jokes
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Tue, Aug 7, 2012 at 5:04 PM, Michael Brooks <
> >> michael@michaelbrooks.ca> wrote:
> >> >>>>>
> >> >>>>> 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 )
> >> >>>>
> >> >>>>
> >> >>>> Can we consider using the other anchor frame types? [1] To
me,
> _blank
> >> >>>> should still exit the app and open the default browser. Perhaps
> _self,
> >> >>>> _parent, or _top can be intercepted to invoke the Child Browser
> (name
> >> >>>> change pending)?
> >> >>>>
> >> >>>> - _blank: The user agent should load the designated document
in a
> new,
> >> >>>> unnamed window.
> >> >>>> - _self: The user agent should load the document in the same
frame
> as
> >> the
> >> >>>> element that refers to this target.
> >> >>>> - _parent: The user agent should load the document into the
> immediate
> >> >>>> FRAMESET parent of the current frame. This value is equivalent
to
> >> _self if
> >> >>>> the current frame has no parent.
> >> >>>> - _top: The user agent should load the document into the full,
> >> original
> >> >>>> window (thus canceling all other frames). This value is equivalent
> to
> >> _self
> >> >>>> if the current frame has no parent.
> >> >>>>
> >> >>>> [1] http://www.w3.org/TR/html401/types.html#type-frame-target
> >> >>>>
> >> >>>> Michael
> >> >>>>
> >> >>>> On Tue, Aug 7, 2012 at 4:58 PM, Jesse <purplecabbage@gmail.com>
> >> wrote:
> >> >>>>
> >> >>>>> Brian,
> >> >>>>> The ChildBrowser does NOT allow bridge access, it is a
dumb view.
> >> >>>>> The only way that it can communicate with the host app
is via url
> >> changes (
> >> >>>>> a'la OAuth, NOT a'la PhoneGap gap:// commands. )
> >> >>>>>
> >> >>>>> Michael,
> >> >>>>> When you install a plugin, you should be aware of what
the plugin
> >> does.
> >> >>>>> This is a developer decision and not a framework responsibility
> IMHO.
> >> >>>>>
> >> >>>>> ChildBrowser name suggestions? Separate thread?
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> On Tue, Aug 7, 2012 at 4:44 PM, Michael Brooks <
> >> michael@michaelbrooks.ca
> >> >>>>>> wrote:
> >> >>>>>
> >> >>>>>> Great writeup Jesse.
> >> >>>>>>
> >> >>>>>> I agree with your reasoning and I like that Child Browser
is not
> >> ruled by
> >> >>>>>> the domain whitelist.
> >> >>>>>>
> >> >>>>>> One concern that I have is around other plugins. Consider
the
> >> scenario of
> >> >>>>>> an asset downloader that may download an archive (tar,
gzip,
> etc),
> >> >>>>> extract
> >> >>>>>> it, and inject the assets into the application's DOM.
Off the top
> >> of my
> >> >>>>>> head, this sort of plugin should be restricted by the
domain
> >> whitelist.
> >> >>>>>>
> >> >>>>>> Michael
> >> >>>>>>
> >> >>>>>> On Tue, Aug 7, 2012 at 4:30 PM, Jesse <purplecabbage@gmail.com>
> >> wrote:
> >> >>>>>>
> >> >>>>>>> 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
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> @purplecabbage
> >> >>>>> risingj.com
> >> >>>>>
> >>
>



-- 
@purplecabbage
risingj.com

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