cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Whitelist defaults
Date Tue, 06 Nov 2012 00:22:09 GMT
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 <purplecabbage@gmail.com> 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 <shazron@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.kadri@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 <shazron@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.kadri@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 <shazron@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 <bowserj@gmail.com>
> >> > wrote:
> >> > > > >
> >> > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <shazron@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message