cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Whitelist: *.doman vs subdomain attribute
Date Fri, 05 Jul 2013 23:03:19 GMT
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