I understand and am already familiar with the configuration for external URLs that do not interfere/launch third party apps or intents. I just want to understand better what's gonna happen with the custom protocols I call, like tel: or mailto:, or even URLs that have custom handlers on each platform.
2014-11-04 14:03 GMT-02:00 Ian Clelland <iclell...@chromium.org>: > On Tue Nov 04 2014 at 10:46:52 AM Frederico Galvão < > frederico.gal...@pontoget.com.br> wrote: > > > So we actually have 4 new plugins: > > org.apache.cordova.whitelist > > org.apache.cordova.legacy-whitelist > > org.apache.cordova.navigation-whitelist > > org.apache.cordova.intent-whitelist > > > > I think that org.apache.cordova.legacy-whitelist is a better name for what > I have published at https://github.com/clelland/cordova-plugin-whitelist > as > org.apache.cordova.whitelist. > > So where I had a single plugin implementing the old behaviour, Andrew has > suggested releasing three plugins: legacy-whitelist, which is what I > implemented; and two new ones: navigation-whitelist, which implements > navigation control, and intent-whitelist, which would control launching > external apps. > > (And there's also the very sound advice of "just skip the whitelist plugins > and use CORS if you can get away with it") > > > > > Right? > > > > If that's the case, then this is not entirely true: > > > > If what > > > you want is no change at all in behaviour, then your upgrade should be > > > just: > > > > > > cordova plugin add org.apache.cordova.whitelist > > > > > > There would be no configuration changes to make: the plugin reads the > old > > > access tags, just as before, and applies the same policies based on > them > > > that it did in 3.6. > > > > > > > > The messaging is still simple, if all you want is backwards compatibility, > but if you want something better, then the instructions are more > complicated, and depend on your actual needs. > > > > > > 2014-11-04 2:13 GMT-02:00 Andrew Grieve <agri...@chromium.org>: > > > > > Since the whitelist plugin blocks only a subset of sub-resource loads > > (just > > > like the existing whitelists), I think we really want to call out that > > > people should not just include the backwards-compatible plugin. Here's > a > > > stab at messaging: > > > > > > > > > If you want nothing to change, use org.apache.cordova.legacy-whitelist. > > If > > > you care about security, then please understand that there are three > > types > > > of whitelists to consider: > > > > > > 1. Network traffic - The whitelist has never been able to fully block > all > > > network requests in this manner (on iOS and Android). Instead, we > > recommend > > > using <meta http-equiv="Content-Security-Policy" content="[POLICY GOES > > > HERE]"> in your <head>, which is supported on Android 4.4 and iOS 7. > > > > > > 2. Navigation - By default the webview is allowed to navigate to any > page > > > within the same directory tree as the start page. If you'd like to > > navigate > > > to a different directory, or to a http(s) address, then you should use > > > org.apache.cordova.navigation-whitelist. > > > > > > 3. Intents - By default all URLs that cause an external action (e.g. > > tel:, > > > sms:, etc) are disabled. If you need to use any of these, then you > should > > > use org.apache.cordova.intent-whitelist. > > > > > > > > > On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland <iclell...@chromium.org> > > > wrote: > > > > > > > On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard <cmarc...@gmail.com> > > > wrote: > > > > > > > > > This sounds very interesting and relatively graceful. > > > > > > > > > > For a user upgrading to this new world, what would the migration > > steps > > > > > look like? Or in other words, what would a rough sketch of the > > upgrade > > > > > guide for this look like? The reason I ask is to see how much pain > > > we'll > > > > > ask our users to go through. > > > > > > > > > > > > > That's certainly a concern -- so for one thing, this would have to be > > on > > > a > > > > 4.x version of any platforms that it applies to. It is a break in > > > backwards > > > > compatibility, so users should at least be prepared for it. > > > > > > > > That said, I've tried to make it as simple as possible for them: If > > what > > > > you want is no change at all in behaviour, then your upgrade should > be > > > > just: > > > > > > > > cordova plugin add org.apache.cordova.whitelist > > > > > > > > There would be no configuration changes to make: the plugin reads the > > old > > > > access tags, just as before, and applies the same policies based on > > them > > > > that it did in 3.6. > > > > > > > > And if your application doesn't rely on access to external sites, > then > > > it's > > > > even simpler -- don't install the plugin, and you're likely more > secure > > > > than you were before. > > > > > > > > > > > > > On Oct 30, 2014, at 4:04 PM, Ian Clelland <iclell...@chromium.org> > > > > wrote: > > > > > > > > > > > I've spent the majority of the week finishing up the > > > whitelist-breakout > > > > > > code, and I'd invite the rest of the community to take a look, > > before > > > > we > > > > > > make anything official. > > > > > > > > > > ------------------------------------------------------------ > > --------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > *Frederico Galvão* > > > > Diretor de Tecnologia > > > > PontoGet Inovação Web > > > > > > ( +55(62) 8131-5720 > > > > * www.pontoget.com.br <http://www.pontoget.com/> > > > -- *Frederico Galvão* Diretor de Tecnologia PontoGet Inovação Web ( +55(62) 8131-5720 * www.pontoget.com.br <http://www.pontoget.com/>
