cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [ios] Feature Request: Adding NSUrlProtocol handling for plugins
Date Fri, 05 Apr 2013 19:00:25 GMT
Idea #1: If there are any <access> tags that have a scheme set, add that
scheme to the list of schemes that are processed by the whitelist. In this
case, it would look like:

<access origin="chrome-extension://*"/>

Idea #2: Android has:

<url-filter value="chrome-extension://" />

It causes all matching URLs to be routed to a plugin to handle. It's used
for both intents and for ICS+, for resource loading. We could do likewise
on iOS to explicitly support plugins serving resources.


I think the first idea is the simpler of the two, but the second idea would
make it possible for plugins to know which (of possibly multiple) webviews
the request came from.





On Fri, Apr 5, 2013 at 12:49 PM, Shazron <shazron@gmail.com> wrote:

> +1 do it
>
> On Friday, April 5, 2013, Michal Mocny wrote:
>
> > I've written a plugin to handle a custom url protocol using
> NSURLProtocol.
> >  However, I had to modify CDVViewController's shouldStartLoadWithRequest:
> > in order to actually have the URL navigation progress to that point.
> >
> > Currently, we allow only a fixed set of schemes (file:, tel:, about:
> etc),
> > then use the whitelist to check if the scheme is allowed, and finally
> > fallback to forwarding everything else to the main native application (in
> > order to handle tel:, sms: etc).
> >
> > The problem is that the whitelist is hard coded to support only exactly
> > http[s] and ftp[s], so no custom schemes are possible.
> >
> > I suspect this was always been planned, but I now propose actually
> adding a
> > config file setting to whitelist url schemes, and plugin.xml should be
> able
> > to add to this list.
> >
> > I'm not sure if there is a comparable need on other platforms, its my
> > impression this isn't necessary on android.
> >
> > If there is no objection I'll file JIRA and get this in soon.
> >
> > -Michal
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message