Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.218.46 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <ee6b66acd95842f5b2e00537e9bf70e8@BL2PR03MB129.namprd03.prod.outlook.com>
References: 
 <CAE6O_-aBHmyw6SKVHuuUZCxYaiaK4v2qh8401K2-SbtPtgm+7w@mail.gmail.com>
 <CAPTyS6DtkdNkkDGVe5bAwRTXUsBK7w_WHa4NDV4Rkrdf9uAQfA@mail.gmail.com>
 <CAE6O_-YsR9CN2GO8T6kkL13EzpQk4HhALV83wi4SKmz9qfFiMg@mail.gmail.com>
 <CABiQX1V7Y18-n=L97S+rwgNH_cMR0GWV4wm0JQ9FGs_1ty_E4g@mail.gmail.com>
 <CAE6O_-b9KCx6Snqj=OLWDnAG=HS9Mww9xj_RA0QnHqBC90Dx4g@mail.gmail.com>
 <CABiQX1U-J6vayb2n9_xadZFy+CSAWX632uQ1mXppjy=VvXDH+w@mail.gmail.com>
 <D07921A4.28A90%tony.homer@intel.com>
 <ee6b66acd95842f5b2e00537e9bf70e8@BL2PR03MB129.namprd03.prod.outlook.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Fri, 31 Oct 2014 13:19:00 -0400
Message-ID: 
 <CABiQX1U3-HjVk=wyApnTMZAkAzv9badn1oxJxaq1i3QJV-zHKQ@mail.gmail.com>
Subject: Re: [iOS 8] WKWebView moving forward
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a113e4bc29a384b0506bb3224

--001a113e4bc29a384b0506bb3224
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Unless you're having the server proxy requests to remote sites, I don't
think CORS headers are necessary.

Tony - awesome stuff! absolutely doing it right. More technical-focused
discussion the better :). Using cookies seems the best way to me since that
covers all requests. Adding headers works only for XHRs.

On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
Kirk.Shoop@microsoft.com> wrote:

> Yes, the handler should be able to add CORS headers to its responses that
> will enable requests from any origin.
>
> For instance adding 'Access-Control-Allow-Origin: *' would allow any
> origin to make a request from the local server.
> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
>
> Similarly Access-Control-Allow-Methods and Access-Control-Allow-Headers
> could be used to define valid requests.
>
> Kirk
>
> Developer
> Microsoft Open Technologies, Inc.
>
> -----Original Message-----
> From: Homer, Tony [mailto:tony.homer@intel.com]
> Sent: Friday, October 31, 2014 8:40 AM
> To: dev@cordova.apache.org
> Subject: Re: [iOS 8] WKWebView moving forward
>
> Last night I added a handler to the Local Web Server plugin that returns
> 403 for non-localhost requests.
> The handler also has a prototype token system to restrict requests to the
> app, but I need to change the approach a bit.
> Currently I set a cookie and the handler just checks for the cookie and
> returns 403 if it is missing.
> This is susceptible to replay attacks from backgrounded apps - not sure i=
f
> that is important or not.
>
> I=C2=B9m going to investigate adding a map to the plugin, then add an ent=
ry for
> every request.
> The entry will be a hash of the request and a random number.
>
> I=C2=B9ll have to wire up support for overriding url loads so that I can =
add
> the header with the random number to the request.
> Then the request handler will look the entry up in the map and remove it =
-
> this should eliminate re-playability.
>
> I=C2=B9m not sure about the CORS issue with camera plugin=C5=A0 I=C2=B9ll=
 be curious to
> test it - maybe it could be addressed by modifying the response in the
> GCDWebServer handler?
>
> Tony
>
> P.S. This is my first attempt participating in discussion on the list -
> let me know if I=C2=B9m doing it wrong!
> Am I wasting my time investigating this?  Should I just leave it Shazron?
>
> On 10/30/14, 9:52 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
>
> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <shazron@gmail.com> wrote:
> >
> >> The port conflict situation has been solved with the latest version
> >>of the  plugin. Passing in a port of "0" will choose a random port.
> >>More details in  the plugin's README.md
> >>
> >Awesome! Why even allow a non-random port?
> >Also learned today that in chrome, webcrypto API is disabled for http
> >origins, but enabled for https. Not sure if this is true for Safari as
> >well, but certainly this change will be a can of worms!
> >
> >
> >>
> >> Ouch - didn't think about Camera plugin and File plugin impact. That
> >>proxy  thing might work, as long as there are no folder name
> >>collisions.
> >>
> >Prefixing all resources into a fake top-level directory will eliminate
> >the folder name collision problem I think.
> >
> >
> >>
> >> My point regarding mixing WKWebView and UIWebView on iOS 8 is, if you
> >>have  a user on iOS 8.x, you want all users on that iOS version to
> >>have the same  experience, and for bug reporting purposes.
> >
> >
> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve <agrieve@chromium.org>
> >> wrote:
> >>
> >> > We could restrict access to the webserver by stuffing a cookie into
> >>the
> >> > webview with an access token, then have the server just 500 on any
> >> request
> >> > missing the cookie. We should also be able to restrict external
> >>requests
> >> > just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't look
> >> > like GCDWebServer supports this, but we can hack it in).
> >> >
> >> > The problem of port conflicts is annoying though. Maybe we try rando=
m
> >> ports
> >> > until one works? Is there any need to use the same port for multiple
> >> runs?
> >> >
> >> > The CORS thing is sad, because it also means things like Camera plug=
in
> >> will
> >> > be broken (can't use resulting URL in <img>).
> >> >
> >> > Although we might just do (this is different than the current mappin=
g
> >>in
> >> > the plugin):
> >> > http://localhost:RANDOM_PORT/www
> >> > http://localhost:RANDOM_PORT/asset-library
> >> > http://localhost:RANDOM_PORT/file-system
> >> >
> >> > to proxy the three locations.
> >> >
> >> > This also means we can't use FileEntry.toURL() and have it work,
> >>unless
> >> > toURL returns http://localhost:RANDOM_PORT/file-system/...   Maybe
> >> that's
> >> > fine?
> >> >
> >> >
> >> > I don't think it's weird that an app will need to support WKWebView =
on
> >> some
> >> > OS versions, and UIWebView on others. That's already the case to
> >>support
> >> > iOS 7.
> >> >
> >> >
> >> >
> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <shazron@gmail.com> wrote:
> >> >
> >> > > This does not preclude using the file url API function I suppose.
> >> Here's
> >> > a
> >> > > flowchart on how I think it would work:
> >>http://i.imgur.com/zq4zreN.png
> >> > >
> >> > >
> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams <tommy@devgeeks.or=
g
> >
> >> > > wrote:
> >> > >
> >> > > > This whole thing reeks of sadness and pain.
> >> > > >
> >> > > > The security implications of this will have to be considered ver=
y
> >> > > > carefully.
> >> > > > On 29 Oct 2014 16:40, "Shazron" <shazron@apache.org> wrote:
> >> > > >
> >> > > > > ## What We Know So Far
> >> > > > >
> >> > > > > 1. Because of the file:// url loading bug, we couldn't support
> >>the
> >> > > > > WKWebView in the iOS 8 GM release. It has since been fixed, fo=
r
> >> > release
> >> > > > > post iOS 8.1 (not sure when), through a new WKWebView API
> >>function
> >> (
> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
> >> > > > > 2. The alternative is embedding a local web server and serving
> >> assets
> >> > > > from
> >> > > > > that
> >> > > > >
> >> > > > > ## Abandon file:// url Loading API Method
> >> > > > >
> >> > > > > My proposal is, we abandon the local file:// url loading metho=
d
> >>in
> >> > (1)
> >> > > > > above, since it will create problems with support.
> >> > > > >
> >> > > > > For example, if we support the new local file url loading API
> >> > function
> >> > > in
> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2, what then? Y=
ou
> >> > would
> >> > > > not
> >> > > > > have WKWebView support for that user, and you would use
> >>UIWebView
> >> > > > instead.
> >> > > > > This will just be confusing, and leads to problems.
> >> > > > >
> >> > > > > With the embedded local web server method, you can support
> >>**any**
> >> > > > version
> >> > > > > of iOS 8.x.
> >> > > > >
> >> > > > > ## Embrace Embedded Local Web Server Method
> >> > > > >
> >> > > > > I have a Cordova plugin that implements this, and it should wo=
rk
> >> with
> >> > > > > cordova-ios 3.7.0:
> >> > > > > https://github.com/shazron/CordovaLocalWebServer
> >> > > > >
> >> > > > > It dynamically updates the <access> tag value when it loads,
> >> > overriding
> >> > > > it
> >> > > > > to the actual location and port. Since it is a plugin, it can =
be
> >> > > > swappable
> >> > > > > (for whatever reason).
> >> > > > >
> >> > > > > It does not solve the problem where any backgrounded app can
> >>access
> >> > our
> >> > > > > local web server.
> >> > > > >
> >> > > > > ## Future Steps
> >> > > > >
> >> > > > > This plugin is already working in cordova-ios 3.7.0
> >>(un-released,
> >> up
> >> > > next
> >> > > > > for vote release).
> >> > > > >
> >> > > > > The wkwebview branch:
> >> > > > >
> >> > > > > 1. Needs be rebased
> >> > > > > 2. Needs to be re-tested
> >> > > > > 3. issues in CB-7043 that relate to the wkwebview have to be
> >> resolved
> >> > > > > 4. branch presented for review to other committers
> >> > > > > 5. resolve any comments and issues from (4)
> >> > > > > 6. wkwebview branch integrated into master
> >> > > > >
> >> > > > > I will work on these items next after getting cordova-ios 3.7.=
0
> >> out.
> >> > > Any
> >> > > > > help is welcome.
> >> > > > >
> >> > > > > ## Migration Issues
> >> > > > >
> >> > > > > If you are migrating to WKWebView from UIWebView, you will los=
e
> >> some
> >> > > > > functionality.
> >> > > > >
> >> > > > > 1. No more whitelist feature (NSURLProtocol is not supported i=
n
> >> > > > WKWebView)
> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS compliant
> >>(this is
> >> > > still
> >> > > > > true if loaded through a file:// url)
> >> > > > > 3. HTML5 offline application cache is not available in
> >>WKWebView (
> >> > > > > https://devforums.apple.com/message/1060452)
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

--001a113e4bc29a384b0506bb3224--