cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Whitelist: *.doman vs subdomain attribute
Date Sat, 06 Jul 2013 22:34:28 GMT
Not sure I understand how it is that this cannot be supported..

Couldn't we allow native plugins to register synchronous "observers" for
the CDVWhitelist URLIsAllowed method, and move the current implementation
out to a core plugin?  Then if your app wants something more complicated,
you can just write a plugin for it.

Looking again at your email, perhaps you mean just that its not possible to
know the type of request?

-Michal


On Sat, Jul 6, 2013 at 3:47 PM, Andrew Lunny <alunny@gmail.com> wrote:

> Yeah it's probably not practical right now. Roll on the
> NavigationController :)
>
> Unifying the declarative whitelist is definitely worthwhile.
>
>
> On 5 July 2013 16:03, Andrew Grieve <agrieve@chromium.org> wrote:
>
> > Love that idea Andrew, but not sure it's doable on iOS. There's no native
> > callback that would tell us the type of request. We could try and pipe
> > through the request URLs to JS, but since our network interception
> happens
> > on a non-UI thread, that would require proxying all requests, which is
> > tough to get right. On Android, the situation is actually the same!
> (ugh).
> >
> > I'm hoping that at least unifying our declarative whitelist should be a
> > small amount of work. I know at least for Android and iOS it will require
> > only small tweaks.
> >
> >
> > On Fri, Jul 5, 2013 at 4:07 PM, Andrew Lunny <alunny@gmail.com> wrote:
> >
> >> We ran into a lot of issues with this at PhoneGap Build, when I was
> >> there. It's very difficult to anticipate all of the use cases that app
> >> developers will have (what kind of resources should be allowed from
> which
> >> domains, where links should open, if links should be followed, etc etc).
> >>
> >> One lower-level option would be to expose a function like iOS's
> >> shouldStartLoadWithRequest[1], which gets passed the URL and the type of
> >> request (script, image, xhr, etc) and returns true/false as to whether
> the
> >> request should be allowed. This would allow for access policies that are
> >> unwieldy or impossible to express declaratively, and as fine-grained as
> any
> >> developer could want. Not sure where that would live in a Cordova 3.0
> >> universe though.
> >>
> >> [1]:
> >>
> http://developer.apple.com/library/ios/#documentation/uikit/reference/UIWebViewDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intf/UIWebViewDelegate
> >>
> >>
> >> On 5 July 2013 12:21, Brian LeRoux <b@brian.io> wrote:
> >>
> >>> TBH I'm still unsure of the entire whitelist thing. It feels like
> >>> we've spent a great deal of time on a feature that is essentially just
> >>> a talking point for security checklists. Our community is otherwise
> >>> uninterested if not outright frustrated by it!
> >>>
> >>> I know the whitelist is pretty tied up to our internals so making it a
> >>> plugin is probably not realistic. Regardless the behavior should be
> >>> normalized across the platforms. I like the Chrome spec.
> >>>
> >>> We should contrast this with the WebAPI [1] stuff Moz is doing and the
> >>> restricted by default Sys Apps thinking [2].
> >>>
> >>> [1]
> >>>
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model
> >>> [2] http://runtime.sysapps.org/#csp-policy
> >>>
> >>>
> >>> On Fri, Jul 5, 2013 at 12:00 PM, Andrew Grieve <agrieve@chromium.org>
> >>> wrote:
> >>> > As another point of reference, here's the white-listing scheme that
> >>> Chrome
> >>> > extensions use:
> >>> >
> >>> > http://developer.chrome.com/extensions/match_patterns.html
> >>> >
> >>> > It uses * for wildcards, but adds some restrictions as to where the
*
> >>> may
> >>> > appear and what schemes are valid.
> >>> >
> >>> > It's not a goal for Cordova to be runnable within Widget containers,
> >>> so I
> >>> > don't think conforming to the widget spec is meaningful, except that
> it
> >>> > saves us from writing our own spec. I think the white-list patterns
> >>> from
> >>> > Chrome Extensions make sense (aside from specifying
> "chrome-extension"
> >>> as a
> >>> > valid scheme).
> >>> >
> >>> >
> >>> >
> >>> > On Fri, Jul 5, 2013 at 2:27 PM, Andrew Grieve <agrieve@chromium.org>
> >>> wrote:
> >>> >
> >>> >> We've had several requests for finer-grain whitelist. The main
ask
> is
> >>> a
> >>> >> way to allow images.
> >>> >>
> >>> >> I think a simple step towards this would be to allow the whitelist
> to
> >>> >> specify patterns that match against the full URL, and not just
the
> >>> domain.
> >>> >>
> >>> >> e.g. <access origin="*.google.com/images/*" />
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Fri, Jul 5, 2013 at 2:05 PM, Ian Clelland <
> iclelland@chromium.org
> >>> >wrote:
> >>> >>
> >>> >>> There seem to be two competing methods for whitelisting domains
> with
> >>> >>> subdomains, and support for each varies by platform.
> >>> >>>
> >>> >>> <access origin="*.example.com" />
> >>> >>>
> >>> >>>    - is supported on ios
> >>> >>>    - is supported on android as of CB-3854
> >>> >>>    - is backwards-compatible with previous versions of cordova
> >>> >>>    - is supported by cordova-cli
> >>> >>>
> >>> >>> <access origin="example.com" subdomains="true" />
> >>> >>>
> >>> >>>    - is supported on android
> >>> >>>    - is supported on BB10
> >>> >>>    - may not be backwards-compatible
> >>> >>>    - is the only method defined in the W3 widgets-access spec
> >>> >>>    - is not supported by cordova-cli*
> >>> >>>
> >>> >>> This situation makes it difficult to create a config.xml for
a
> >>> project
> >>> >>> which will successfully work on all platforms.
> >>> >>>
> >>> >>> *(cordova-mobile-spec, for instance, contains <access origin="
> >>> apache.org"
> >>> >>> subdomains="true" /> in its config.xml, which gets translated
as
> >>> <access
> >>> >>> origin="apache.org" /> in the platform config files, and
> >>> subsequently
> >>> >>> fails
> >>> >>> everywhere.)
> >>> >>>
> >>> >>> I think that the subdomains attribute is the right way forward,
as
> >>> it is
> >>> >>> endorsed by the W3C, and I believe that we are ostensibly trying
to
> >>> >>> conform
> >>> >>> to the widgets spec for our config.xml files.
> >>> >>>
> >>> >>> To that end, I'd like to make the subdomains attribute work
on all
> >>> >>> platforms (I'll take care of iOS; I don't know if any others
need
> >>> fixing)
> >>> >>> and also make it work in CLI. I don't think we should remove
> support
> >>> for
> >>> >>> the wildcard domains, for backwards compatibility, but then
again,
> >>> maybe
> >>> >>> 3.0 is the right time and place for that.
> >>> >>>
> >>> >>> If there are no objections, I'll create the issues and start
> >>> implementing
> >>> >>> this (with as much backwards compatibility as I can manage)
> >>> >>>
> >>> >>> Ian
> >>> >>>
> >>> >>
> >>> >>
> >>>
> >>
> >>
> >
>

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