What Anis said last is what I meant. Since BB and Android have this behaviour already this doesn't impact those platforms as much. Will wait for comments until tomorrow then I will add some JIRA task(s).
On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI <anis.ka...@gmail.com> wrote: > On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote: > > > Why would we require a new property? We're just talking about adding * as > > the default property. > > > > I believe this applied only if we did a debug/release mode strategy. Adding > (*) as default doesn't require a new property from what I understand. > > > > > > (Also, Jesse, I have talked to many Cordova devs whom have expressed > > frustration with our default.) > > > > I feel we have consensus enough to document and add this default. > > > > > > On Mon, Nov 5, 2012 at 3:26 PM, Shazron <shaz...@gmail.com> wrote: > > > > > Well it's all or nothing. There is no "dev" mode with respect to the > > plist > > > itself as it is right now, unless we want to add yet another plist > > > property. > > > > > > > > > On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI <anis.ka...@gmail.com> > wrote: > > > > > > > I guess the consensus is to whitelist everything (*) all the time. > > > > > > > > My opinion is that there should be some dev mode where (*) is set and > > > then > > > > a release mode where you'd specify your hosts. > > > > > > > > > > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron <shaz...@gmail.com> wrote: > > > > > > > > > We've had the discussion. So what is the decision/consensus? Leave > as > > > is, > > > > > or add "*" to default settings for all, with a warning in the > console > > > > log? > > > > > > > > > > > > > > > > > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser <bows...@gmail.com> > > wrote: > > > > > > > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <shaz...@gmail.com> > > wrote: > > > > > > > Echoing Anis here. The easiest use case is for corporate use > > > > > (internal), > > > > > > > where any connections are restricted to a certain domain for > > > paranoid > > > > > IT > > > > > > > types. > > > > > > > > > > > > > > I can see the case of us allowing everything _by default_ > though > > > (eg > > > > > > adding > > > > > > > the '*'), which really should have been the default so as to be > > > > > > "backwards > > > > > > > compatible" with how it was before the whitelist came in. The > > > system > > > > > > could > > > > > > > detect this sole wildcard entry, and print out a warning in the > > > > console > > > > > > > log, as well as the documentation of course pointing this out > -- > > > the > > > > > > latter > > > > > > > which we should have done in the first place. > > > > > > > > > > > > OK, that sounds cool, but does that mean that in six months, > we're > > > > > > going to deprecate this behaviour and get more aggressive with > the > > > > > > whitelist? > > > > > > > > > > > > BTW: In the event that the whitelist isn't found based on the > code > > > > > > that I'm looking at here, Android should block everything and > fire > > > > > > default web intents. If it's not doing this, that's a bug! When > we > > > > > > refer to defaults, are we referring to the config.xml that we're > > > > > > circulating? > > > > > > > > > > > > Also, how are we testing this whitelisting feature? I can tell > you > > > > > > that doing it in JS alone wouldn't be enough. > > > > > > > > > > > > Joe > > > > > > > > > > > > > > > > > > > > >
