On Mon, May 11, 2015 at 1:56 PM, Nikhil Khandelwal <nikhi...@microsoft.com> wrote:
> Responses inline. > > -----Original Message----- > From: Steven Gill [mailto:stevengil...@gmail.com] > Sent: Thursday, May 7, 2015 6:17 PM > To: dev@cordova.apache.org > Subject: Re: Cordova 5.0 user feedback - move to npm & whitelist plugin > > (1) older versions of our docs point to plugins.cordova.io 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. > http://cordova.apache.org/docs/en/4.0.0/guide_support_index.md.html#Platform%20Support > . > > 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. > http://markmail.org/search/?q=Android%27s+new+Whitelist+Plugins#query:Android%27s%20new%20Whitelist%20Plugins+page:1+mid:z2r2sj5e3kvrnqv6+state:results > 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. > > I agree that needing the new whitelist plugin to make network calls is unfortunate. I know Ian really wanted everything to secure by default, and having network access via a plugin means you can update the plugin separately if there are bugs. I think it might be a bit late to change things now though. Better to just stick with it rather than changing things again and again. > > On Thu, May 7, 2015 at 8:55 AM, Nikhil Khandelwal <nikhi...@microsoft.com> > wrote: > > > 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: > > > > - https://issues.apache.org/jira/browse/CB-8969 > > > > - > > http://stackoverflow.com/questions/29735597/cordova-5-0-0-android-app- > > can-not-connect-to-internet-using-android-4-0-0 > > > > - > > http://stackoverflow.com/questions/30060534/ajax-requests-fail-after-u > > 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: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
