cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikhil Khandelwal <>
Subject RE: Cordova 5.0 user feedback - move to npm & whitelist plugin
Date Mon, 11 May 2015 17:56:42 GMT
Responses inline.

-----Original Message-----
From: Steven Gill [] 
Sent: Thursday, May 7, 2015 6:17 PM
Subject: Re: Cordova 5.0 user feedback - move to npm & whitelist plugin

(1) older versions of our docs point to for plugin documentation. We haven't
pointed people to github for plugin docs. Those docs are accurate with the ID of the plugin.
Adding a section to the readme about needing cordova 5+ isn't a bad idea.

[NK] There are places that this is not true.

The plan is to switch our tools to grab from npm first and CPR second. I believe we discussed
doing this around the time CPR goes read only. Giving IDE's and people using older versions
a chance to upgrade.

We can publish updated plugins to CPR, but it is going to be quite a bit of work. I created
old-id branches for our core plugins that revert the commits changing the ID and the commits
where I change internal plugin references from org.apache.cordova.* to cordova-plugin-*. It
was a fairly large change. The reason for the major jump was the plugin id change. I'd recommend
them sticking the versioning they are on instead of copying the version of the npm series.
The major version bump wasn't due to a change in functionality in the plugins themselves.

If we want to release updated plugins to CPR, someone will need to do the work to cherry-pick
the new commits into old-id and do a separate vote for them.

[NK] I understand this is a lot of work. Alternatlively, shall we change the behavior of the
CLI to use npm first - even for old ids - perhaps, as part of 5.1 tools release? There is
not much value in old Ids causing stale, old version of plugin getting downloaded from CPR.

(2) It is a fairly recent change. Any new app made with cordova-cli 5+ will auto include the
whitelist plugin due to the hello world config.xml including it as a dependency. I think we
need to document it more and make more noise within the community about it. iOS 4.0 will also
require the whitelist plugin when it gets released. The more prepared we are, the better.

As for re-enabling network access by default, I wasn't really part of the original thread
so I will leave it to the people who were to discuss that further.

[NK] I agree that making more noise is the right short term move to help people upgrading
to 5.0 realize this. I still believe that network access should be enabled in the platform
by default without any plugins. For controlling network access, devs should either use CSP
or a whitelist plugin that gets the chance to override the networking behavior. Andrew, Michael,
and Ian are most familiar with the decision around this.

Additionally, on prepare, platforms should see the use of access tags and encourage users
to use one of the whitelist plugins if they have not already done so.

On Thu, May 7, 2015 at 8:55 AM, Nikhil Khandelwal <>

> There is a bunch of confusion with Cordova 5.0 users because of these 
> two
> changes:
> 1. Move to npm for plugins (There have been multiple PRs trying to 
> update plugin docs to reference the old id instead of the new one - 
> because people are still using the old version of the CLI)
> 2. No network access in Android 4.0 without whitelist plugin:
>               -
>               -
> can-not-connect-to-internet-using-android-4-0-0
> -
> pgrading-to-cordova-5-0-cordova-android4-0
> I think for the (1), I suggest we do the following:
> 1.       Update the plugin documentation that the old id can be used for
> older CLI versions.
> 2.       Either update the CPM with 1.0 versions of the plugins or have
> the CLI get core plugins from npm first then CPR even with the old id.
> Using the old id because they were hardcoded in IDEs etc, devs are 
> getting older version of the plugins.
> For (2), I think we should re-visit making whitelist part of the 
> Android platform again or some other way of enabling network access by 
> default. No network access (XHR) for a platform by default is a big 
> change that's not well understood and not necessarily more secure. I'm 
> new to this, but I did not fully understood the goals of moving the 
> whitelisting to a plugin instead of it being part of the core.
> Thanks,
> Nikhil

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message