cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Whitelist: *.doman vs subdomain attribute
Date Mon, 08 Jul 2013 19:01:10 GMT
+!


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