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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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) > > > > > >
