yes... yes I did... :) Pushed now. On Wed, Mar 11, 2015 at 5:49 PM, Steven Gill <[email protected]> wrote:
> Hey Andrew, > > I don't see the new plugins in coho yet. Did you forget to push them? > > On Wed, Mar 11, 2015 at 7:35 AM, Andrew Grieve <[email protected]> > wrote: > > > Done! They are now alive at their now spots and added to coho's plugins > > list. > > > > On Thu, Mar 5, 2015 at 3:49 PM, Jesse <[email protected]> wrote: > > > > > +1 > > > better late than never > > > > > > @purplecabbage > > > risingj.com > > > > > > On Thu, Mar 5, 2015 at 12:39 PM, Andrew Grieve <[email protected]> > > > wrote: > > > > > > > Going with it: https://issues.apache.org/jira/browse/INFRA-9238 > > > > > > > > On Wed, Mar 4, 2015 at 11:22 PM, Michal Mocny <[email protected]> > > > wrote: > > > > > > > > > +1 to names. > > > > > > > > > > On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve < > [email protected]> > > > > > wrote: > > > > > > > > > >> No comments about the names yet, but I'm now leaning towards: > > > > >> > > > > >> cordova-plugin-legacy-whitelist > > > > >> > > > > >> and > > > > >> > > > > >> cordova-plugin-whitelist > > > > >> > > > > >> as the two new git repos to create (rather than "url-policy") > > > > >> > > > > >> On Wed, Mar 4, 2015 at 8:49 PM, Andrew Grieve < > [email protected] > > > > > > > >> wrote: > > > > >> > > > > >> > I think how Cordova works right now was the best way. Have > access > > > > >> blocked > > > > >> > by default, but have a <access origin="*"/> in the default > > template. > > > > It > > > > >> > makes the setting visible, while still working out-of-the-box. > > > > >> > > > > > >> > If we turned on requests when no whitelist plugin is installed, > > then > > > > >> > existing apps that have <access> tags will have their whitelist > > > > removed > > > > >> > with 4.0.0 and not know it. If someone updates and their app > can't > > > hit > > > > >> the > > > > >> > network anymore, then I think Stack Overflow will tell them why > > > pretty > > > > >> > quickly. We should also be very clear in the release notes and > > > upgrade > > > > >> > guide. > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > On Wed, Mar 4, 2015 at 7:54 PM, Nikhil Khandelwal < > > > > >> [email protected]> > > > > >> > wrote: > > > > >> > > > > > >> >> I like Ian's proposal of blocking network access only when a > > > > whitelist > > > > >> >> plugin is added to do so and is choosing to override the > default > > > > >> behavior. > > > > >> >> > > > > >> >> Scanning config.xml on upgrade might be a good way to warn devs > > to > > > > >> refer > > > > >> >> them to use this plugin. These changes should also be > documented > > in > > > > the > > > > >> >> migration guide from Android 3.x to 4.0. > > > > >> >> > > > > >> >> Thanks, > > > > >> >> Nikhil > > > > >> >> > > > > >> >> > > > > >> >> -----Original Message----- > > > > >> >> From: Jesse [mailto:[email protected]] > > > > >> >> Sent: Wednesday, March 4, 2015 11:05 AM > > > > >> >> To: [email protected] > > > > >> >> Subject: Re: Android's new Whitelist Plugins > > > > >> >> > > > > >> >> I like the defaults as discussed, regardless of how they are > > > > achieved. > > > > >> >> ie. network yes, intents no > > > > >> >> This is similar to how a plain webview works if you add it to a > > > > native > > > > >> >> app on ios or android, at least the network part, not sure what > > the > > > > >> default > > > > >> >> intent handling is. > > > > >> >> > > > > >> >> Are there portions of this functionality that make more sense > as > > > part > > > > >> of > > > > >> >> the platform native code? To me a plugin that is installed by > > > > default > > > > >> is > > > > >> >> just modular platform code. Is there ever a reason to NOT want > > this > > > > >> plugin, > > > > >> >> versus just opening up access? > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> @purplecabbage > > > > >> >> risingj.com > > > > >> >> > > > > >> >> On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny < > > [email protected]> > > > > >> wrote: > > > > >> >> > > > > >> >> > I've been working on adding support to just install the > > whitelist > > > > >> >> > plugin by default, and to add the <access origin="*"> to the > > > > default > > > > >> >> app. > > > > >> >> > > > > > >> >> > Is that sufficient? I think we may still need to do what Ian > > > > >> suggests > > > > >> >> > and prompt on upgrade (or prepare)? > > > > >> >> > > > > > >> >> > For downstreams, especially IDE based ones, they will need to > > > make > > > > >> >> > sure the plugin is added by default however they do that. > > > > >> >> > > > > > >> >> > On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland < > > > > >> [email protected]> > > > > >> >> > wrote: > > > > >> >> > > > > > >> >> > > On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal < > > > > >> >> > [email protected]> > > > > >> >> > > wrote: > > > > >> >> > > > > > > >> >> > > > Here are my thoughts on the default behavior: > > > > >> >> > > > - navigation should be disabled. > > > > >> >> > > > - XHR & network request should be enabled. > > > > >> >> > > > > > > > >> >> > > > > > > >> >> > > And application launch through intent URLs should also be > > > > disabled. > > > > >> >> > > (IMO) > > > > >> >> > > > > > > >> >> > > That's not a bad default -- it enables CSP usage by > default, > > > > which > > > > >> I > > > > >> >> > think > > > > >> >> > > is good. It also (I think) means we're giving up on > > suggesting > > > > that > > > > >> >> > network > > > > >> >> > > requests can be completely blocked by default, because > that's > > > > >> >> > > definitely not the case on Android. > > > > >> >> > > > > > > >> >> > > We can implement this within the new framework: there is > the > > > idea > > > > >> of > > > > >> >> > > a 'default policy' that only comes into effect when no > > plugins > > > > take > > > > >> >> > > responsibility for the whitelist. As soon as any plugin, > > > though, > > > > >> >> > > handles the shouldAllowRequest() call, for instance, the > > > default > > > > >> >> > > policy is no longer in effect, and it is a true whitelist > > > > >> >> > > (block-by-default) > > > > >> >> > > > > > > >> >> > > My biggest concern with this is that developers are going > to > > > > >> blindly > > > > >> >> > update > > > > >> >> > > to Cordova 4.0.0, and when their app *just works*, they are > > not > > > > >> >> > > going to realize that they are actually less secure than > > > before. > > > > >> >> > > (Without a > > > > >> >> > plugin, > > > > >> >> > > we've opened up all network access) > > > > >> >> > > > > > > >> >> > > Idea -- maybe we can scan config.xml -- at run time, or on > > > > prepare, > > > > >> >> > > or on upgrade -- and if we see any access tag other than > > > <access > > > > >> >> > > origin="*"> we can display a loud message, suggesting > > strongly > > > > that > > > > >> >> > > they install an appropriate plugin. > > > > >> >> > > > > > > >> >> > > Ian > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > > >> >> > > > 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-po > > > > >> >> > > > > > > licy > > > > >> >> > > > > > > > > > > >> >> > > > > > > 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) > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > >> >> > > > > > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > >> >> > > > --------------------------------------------------------------------- > > > > >> >> To unsubscribe, e-mail: [email protected] > > > > >> >> For additional commands, e-mail: [email protected] > > > > >> >> > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > >
