I am good with all of that. Can we fully document this before we jump to doing it?
On Thu, Aug 9, 2012 at 12:11 PM, Dave Johnson <[email protected]>wrote: > > - is there a guarantee that the InAppBrowser is present, after all it is > a > > plugin, even when it becomes a core plugin, it is still optional, isn't > it? > > yes that changes the options. If not present then all things that go > to InAppBrowser just go to native browser. > > > - is there still an InAppBrowser api where I can actively attempt to load > > any url in the InAppBrowser? ( whether it is whitelisted or not ) > > sure > > > On Thu, Aug 9, 2012 at 11:58 AM, Jesse <[email protected]> wrote: > > More than an hour to make a decision, we have been talking about this for > > months. > > > > Questions: > > - is there a guarantee that the InAppBrowser is present, after all it is > a > > plugin, even when it becomes a core plugin, it is still optional, isn't > it? > > - is there still an InAppBrowser api where I can actively attempt to load > > any url in the InAppBrowser? ( whether it is whitelisted or not ) > > > > > > > > On Thu, Aug 9, 2012 at 11:49 AM, Brian LeRoux <[email protected]> wrote: > > > >> ? > >> > >> On Thu, Aug 9, 2012 at 11:33 AM, Jesse <[email protected]> wrote: > >> > Can we get more than an hour? > >> > > >> > On Thu, Aug 9, 2012 at 11:24 AM, Brian LeRoux <[email protected]> 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 > >> >> <[email protected]> wrote: > >> >> > Nice Dave, those conditions make sense to me. > >> >> > > >> >> > On Thu, Aug 9, 2012 at 10:54 AM, Dave Johnson < > >> [email protected] > >> >> >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 <[email protected]> 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 > >> >> >> > <[email protected]> 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 <[email protected]> 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 < > >> >> >> [email protected]> 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 < > [email protected]> > >> >> >> 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 < > >> >> >> [email protected] > >> >> >> >>>>>> 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 < > >> [email protected]> > >> >> >> 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 < > >> [email protected]> > >> >> >> wrote: > >> >> >> >>>>>>> > >> >> >> >>>>>>>> On Mon, Aug 6, 2012 at 3:52 PM, Jesse MacFadyen < > >> >> >> >>>>>> [email protected] > >> >> >> >>>>>>>>> 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 > >> > > > > > > > > -- > > @purplecabbage > > risingj.com > -- @purplecabbage risingj.com
