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 Mon, 08 Jul 2013 20:19:15 GMT
https://issues.apache.org/jira/browse/CB-4093


On Mon, Jul 8, 2013 at 3:01 PM, Shazron <shazron@gmail.com> wrote:

> +!
>
>
> On Mon, Jul 8, 2013 at 5:41 AM, Andrew Grieve <agrieve@chromium.org>wrote:
>
>> I meant it wouldn't be possible to route the callback to JS.
>>
>> With UriResolver.java, Android plugins could actually implement their own
>> whitelist now. For iOS, NSURLProtocol would let you do this as well. So,
>> we
>> could move the whitelist to be a plugin at least on iOS & Android. Let's
>> unify first though.
>>
>>
>> On Sat, Jul 6, 2013 at 7:18 PM, Andrew Lunny <alunny@gmail.com> wrote:
>>
>> > Knowing the type of request is the tricky bit.
>> >
>> > I haven't looked at the relevant code in a long time, but your approach
>> > sounds sound; it's similar to the chrome webRequest module:
>> > http://developer.chrome.com/extensions/webRequest.html
>> >
>> >
>> > On 6 July 2013 15:34, Michal Mocny <mmocny@chromium.org> wrote:
>> >
>> >> 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