You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Nikhil Khandelwal <ni...@microsoft.com> on 2015/05/07 17:55:01 UTC
Cordova 5.0 user feedback - move to npm & whitelist plugin
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-upgrading-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
Re: Cordova 5.0 user feedback - move to npm & whitelist plugin
Posted by Raymond Camden <ra...@gmail.com>.
On Thu, May 7, 2015 at 8:16 PM, Steven Gill <st...@gmail.com> wrote:
>
> (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.
Oh wow, didn't know iOS would also need this. I'll make some noise
(via blog) today.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Cordova 5.0 user feedback - move to npm & whitelist plugin
Posted by Andrew Grieve <ag...@chromium.org>.
It's here:
cordova-lib/cordova-lib/node_modules/cordova-app-hello-world/config.xml
A use can change the defaults by providing a config.xml within their own
template (--copy-from target)
On Wed, May 13, 2015 at 10:51 AM, Raymond Camden <ra...@gmail.com>
wrote:
> Ah interesting. Where is the default config.xml actually defined? I
> assume it is baked in and a user can't change the default used?
>
> On Tue, May 12, 2015 at 11:02 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > if you use --copy-from and the template doesn't already have a
> config.xml,
> > then the default config.xml will be used.
> >
> > I wouldn't expect what you describe if your template already had a
> > config.xml
> >
> > On Tue, May 12, 2015 at 10:46 AM, Raymond Camden <
> raymondcamden@gmail.com>
> > wrote:
> >
> >> So query - I thought the whitelist plugin was being added because it
> >> was in the default Cordova sample config.xml - but when I built a new
> >> project and used --copy-from, it *also* installed the plugin. So is it
> >> just *always* added?
> >>
> >> On Tue, May 12, 2015 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
> >> wrote:
> >> > On Mon, May 11, 2015 at 1:56 PM, Nikhil Khandelwal <
> >> nikhilkh@microsoft.com>
> >> > wrote:
> >> >
> >> >> Responses inline.
> >> >>
> >> >> -----Original Message-----
> >> >> From: Steven Gill [mailto:stevengill97@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 <
> >> nikhilkh@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-unsubscribe@cordova.apache.org
> >> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >>
> >> >>
> >>
> >>
> >>
> >> --
> >>
> ===========================================================================
> >> Raymond Camden, Developer Advocate for MobileFirst at IBM
> >>
> >> Email : raymondcamden@gmail.com
> >> Blog : www.raymondcamden.com
> >> Twitter: raymondcamden
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
>
>
> --
> ===========================================================================
> Raymond Camden, Developer Advocate for MobileFirst at IBM
>
> Email : raymondcamden@gmail.com
> Blog : www.raymondcamden.com
> Twitter: raymondcamden
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Cordova 5.0 user feedback - move to npm & whitelist plugin
Posted by Raymond Camden <ra...@gmail.com>.
Ah interesting. Where is the default config.xml actually defined? I
assume it is baked in and a user can't change the default used?
On Tue, May 12, 2015 at 11:02 AM, Andrew Grieve <ag...@chromium.org> wrote:
> if you use --copy-from and the template doesn't already have a config.xml,
> then the default config.xml will be used.
>
> I wouldn't expect what you describe if your template already had a
> config.xml
>
> On Tue, May 12, 2015 at 10:46 AM, Raymond Camden <ra...@gmail.com>
> wrote:
>
>> So query - I thought the whitelist plugin was being added because it
>> was in the default Cordova sample config.xml - but when I built a new
>> project and used --copy-from, it *also* installed the plugin. So is it
>> just *always* added?
>>
>> On Tue, May 12, 2015 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> > On Mon, May 11, 2015 at 1:56 PM, Nikhil Khandelwal <
>> nikhilkh@microsoft.com>
>> > wrote:
>> >
>> >> Responses inline.
>> >>
>> >> -----Original Message-----
>> >> From: Steven Gill [mailto:stevengill97@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 <
>> nikhilkh@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-unsubscribe@cordova.apache.org
>> >> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>
>> >>
>>
>>
>>
>> --
>> ===========================================================================
>> Raymond Camden, Developer Advocate for MobileFirst at IBM
>>
>> Email : raymondcamden@gmail.com
>> Blog : www.raymondcamden.com
>> Twitter: raymondcamden
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
--
===========================================================================
Raymond Camden, Developer Advocate for MobileFirst at IBM
Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Cordova 5.0 user feedback - move to npm & whitelist plugin
Posted by Andrew Grieve <ag...@chromium.org>.
if you use --copy-from and the template doesn't already have a config.xml,
then the default config.xml will be used.
I wouldn't expect what you describe if your template already had a
config.xml
On Tue, May 12, 2015 at 10:46 AM, Raymond Camden <ra...@gmail.com>
wrote:
> So query - I thought the whitelist plugin was being added because it
> was in the default Cordova sample config.xml - but when I built a new
> project and used --copy-from, it *also* installed the plugin. So is it
> just *always* added?
>
> On Tue, May 12, 2015 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > On Mon, May 11, 2015 at 1:56 PM, Nikhil Khandelwal <
> nikhilkh@microsoft.com>
> > wrote:
> >
> >> Responses inline.
> >>
> >> -----Original Message-----
> >> From: Steven Gill [mailto:stevengill97@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 <
> nikhilkh@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-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
>
>
> --
> ===========================================================================
> Raymond Camden, Developer Advocate for MobileFirst at IBM
>
> Email : raymondcamden@gmail.com
> Blog : www.raymondcamden.com
> Twitter: raymondcamden
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Cordova 5.0 user feedback - move to npm & whitelist plugin
Posted by Raymond Camden <ra...@gmail.com>.
So query - I thought the whitelist plugin was being added because it
was in the default Cordova sample config.xml - but when I built a new
project and used --copy-from, it *also* installed the plugin. So is it
just *always* added?
On Tue, May 12, 2015 at 9:21 AM, Andrew Grieve <ag...@chromium.org> wrote:
> On Mon, May 11, 2015 at 1:56 PM, Nikhil Khandelwal <ni...@microsoft.com>
> wrote:
>
>> Responses inline.
>>
>> -----Original Message-----
>> From: Steven Gill [mailto:stevengill97@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 <ni...@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-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
--
===========================================================================
Raymond Camden, Developer Advocate for MobileFirst at IBM
Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Cordova 5.0 user feedback - move to npm & whitelist plugin
Posted by Andrew Grieve <ag...@chromium.org>.
On Mon, May 11, 2015 at 1:56 PM, Nikhil Khandelwal <ni...@microsoft.com>
wrote:
> Responses inline.
>
> -----Original Message-----
> From: Steven Gill [mailto:stevengill97@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 <ni...@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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
RE: Cordova 5.0 user feedback - move to npm & whitelist plugin
Posted by Nikhil Khandelwal <ni...@microsoft.com>.
Responses inline.
-----Original Message-----
From: Steven Gill [mailto:stevengill97@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.
On Thu, May 7, 2015 at 8:55 AM, Nikhil Khandelwal <ni...@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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Cordova 5.0 user feedback - move to npm & whitelist plugin
Posted by Steven Gill <st...@gmail.com>.
(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.
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.
(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.
On Thu, May 7, 2015 at 8:55 AM, Nikhil Khandelwal <ni...@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-upgrading-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
>
Re: Cordova 5.0 user feedback - move to npm & whitelist plugin
Posted by Raymond Camden <ra...@gmail.com>.
> 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.
I'm reminded of the bump for 3.0 when everything became a plugin. All
of a sudden, none of the built in stuff (well, previously built in
stuff) worked anymore. I think folks got over that (and
bloggers/presenters/etc repeated it again and again), but this I can
see being a thorn in people's sides for a while. I don't necessarily
have a great answer (I'd like to see more discussion) but I think it
needs reconsidering.
--
===========================================================================
Raymond Camden, Developer Advocate for MobileFirst at IBM
Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org