Adding * by default SGTM. Having separate debug/release whitelists sounds dangerous though. You don't want your app to work in debug mode and then be broken when you release it.
On Mon, Nov 5, 2012 at 7:26 PM, Anis KADRI <[email protected]> wrote: > I confirm that Android also uses config.xml. > > > On Mon, Nov 5, 2012 at 4:22 PM, Shazron <[email protected]> wrote: > > > I would think all unsupported devices for the whitelist feature remain > > unsupported (and is documented as such: > > > > > http://docs.phonegap.com/en/2.2.0/guide_whitelist_index.md.html#Domain%20Whitelist%20Guide > > ) > > > > > > On Mon, Nov 5, 2012 at 4:14 PM, Jesse <[email protected]> wrote: > > > > > Does this mean that whitelists should be added to Bada, Symbian, > > > WebOS, Windows Phone, and Windows 8? > > > > > > Also, while we are discussing it, wouldn't it be good to have all > > > platforms have a consistent way of defining access-permissions ? > > > > > > Android:: res/xml/cordova.xml > > > Blackberry:: www/config.xml > > > iOS:: Cordova.plist > > > Tizen:: config.xml > > > > > > > > > > > > > > > > > > On Mon, Nov 5, 2012 at 3:58 PM, Shazron <[email protected]> wrote: > > > > 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 <[email protected]> > > wrote: > > > > > > > >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux <[email protected]> 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 <[email protected]> > 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 < > [email protected]> > > > >> 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 <[email protected]> > > > 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 < > > [email protected]> > > > >> > wrote: > > > >> > > > > > > > >> > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron < > [email protected] > > > > > > >> > 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 > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > -- > > > @purplecabbage > > > risingj.com > > > > > >
