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 <shaz...@gmail.com> 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 <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 >> > > > > > >> > > > > >> > > > >> > > >> > >> -- @purplecabbage risingj.com
