started a wiki page to document; no one has to jump into doing anything until comfortable (obviously?)
http://wiki.apache.org/cordova/InAppBrowser On Thu, Aug 9, 2012 at 12:16 PM, Jesse <[email protected]> wrote: > 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
