incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [DISCUSS] window.open target blank
Date Thu, 09 Aug 2012 19:23:14 GMT
Great write-up - thanks Jesse and all.

Response to:
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 )

Answer:
I envision a token based system -- the ChildBrowser (or any other
plugin), generates a token, and a plugin name identifier - , and
registers it with the CDVURLProtocol. The plugin then sets a known
http header (tbd) that it will set with the token value. This
exception when encountered will bypass the whitelist, and is logged to
console (just in case of shenanigans).

eg https://github.com/phonegap/phonegap-plugins/blob/master/iOS/ChildBrowser/ChildBrowserViewController.m#L184
Instead of a NSURLRequest, create a NSMutableURLRequest and set the
expected header with token.

In here we do the whitelist exception decision based on the header+token:
https://github.com/apache/incubator-cordova-ios/blob/master/CordovaLib/Classes/CDVURLProtocol.m#L41

On Thu, Aug 9, 2012 at 11:33 AM, Jesse <purplecabbage@gmail.com> wrote:
> 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
View raw message