cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lunny <alu...@gmail.com>
Subject Re: Whitelist: *.doman vs subdomain attribute
Date Sat, 06 Jul 2013 19:47:35 GMT
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