cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikhil Khandelwal <nikhi...@microsoft.com>
Subject RE: Android's new Whitelist Plugins
Date Wed, 04 Mar 2015 01:20:38 GMT
Here are my thoughts on the default behavior:
- navigation should be disabled.
- XHR & network request should be enabled.

The plugin name is fine.

I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS.
This default behavior should work with the platform and should not require a plugin. This
inhibits users from getting the ground running on a Cordova app. It breaks existing templates
in IDEs and other downstream CLIs as well - as all of them need to include this plugin to
have any network access work.

Thanks,
Nikhil


-----Original Message-----
From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
Sent: Tuesday, March 3, 2015 11:22 AM
To: dev
Subject: Re: Android's new Whitelist Plugins

I've filed a JIRA issue with my thoughts on how to approach this:
https://issues.apache.org/jira/browse/CB-8597

On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Like your ideas a lot. Updating the project template makes a lot of sense.
>
> Tried to make it clear in the README, so if any part was not clear 
> please fix it. But, the CSP tag is the more important bit, since 
> <access> can't actually block all requests. The only reason to even 
> leave <access> in there is to support pre-kitkat webviews, where no 
> CSP support exists. CSP is also used to set a navigation whitelist for 
> subframes, which the native side is not able to do.
>
> On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny <mmocny@chromium.org> wrote:
>
> > My thoughts:
> >
> > - The split between <allow-navigation>, <allow-intent>, and <access>:
> Like
> > it a lot.
> > - I think the defaults *for the plugin* are very reasonable.  
> > However, we may want to provide a default set of tags for the hello 
> > world app.  A
> year
> > or so ago we added a default access * whitelist and I think maybe we
> should
> > continue that.  (on the other hand, I've gotten used to explicitly 
> > whitelisting every url as part of chrome packaged app development 
> > and its not so bad).
> >   - Additionally, that means this plugin should be installed by default.
> > As we discussed this morning, with the new plugin --save 
> > functionality we could just add this to the helloworld config.xml, I think!
> > - Do you really need a CSP meta tag *and* <access> declarations?   Thats
> > what the README.md implies, but I would assume CSP trumps?
> >
> > -Michal
> >
> > On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> >
> > > I've tried to explain it in the plugin's readme:
> > >
> > > https://github.com/apache/cordova-plugins/tree/master/url-policy
> > >
> > > Some points for discussion:
> > > - What should the default behaviour be for the three whitelists 
> > > (what should happen if not whitelist plugin is installed).
> > >   - right now it can't open external URLs
> > >   - and can't do XHRs to http(s)
> > > - Is the plugin name decent ("url-policy"). We should make a 
> > > dedicated
> > git
> > > repo for it (as well as for legacy-whitelist plugin)
> > >
> >
>
Mime
View raw message