Sorry for dropping this thread for a week; let me see if I can address that
--
By default, for brand new apps created with Cordova 4.x with no plugins,
those will be blocked (this includes protocols like tel: and mailto:) .
This was considered to be a security issue earlier this year, and we put
m
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 platfor
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 or
On Mon, Nov 3, 2014 at 11:13 PM, Andrew Grieve wrote:
> 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 messagi
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
Right?
If that's the case, then this is not entirely true:
If what
> you want is no change at all in behaviour, then you
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.lega
On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard 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
Sounds great Ian! Very elegant actually.
Suggestion: patch cordova-cli to warn if there is an tag and
no cordova-plugin-whitelist?
-Michal
On Mon, Nov 3, 2014 at 4:04 PM, Marcel Kinard wrote:
> This sounds very interesting and relatively graceful.
>
> For a user upgrading to this new world,
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 throug
Looks good to me.
As I understood it, updating cordova and installing the
cordova-plugin-whitelist will bring my project up to par with what I
already have regarding external urls that don't launch external
applications.
Now, regarding the ones that do (launch external applications), what
happens
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.
In order to retain some kind of backward compatibility with existing apps
(because it's a terrible situation for everyone when we
11 matches
Mail list logo
