cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kirk Shoop (MS OPEN TECH)" <Kirk.Sh...@microsoft.com>
Subject RE: [iOS 8] WKWebView moving forward
Date Fri, 31 Oct 2014 16:12:15 GMT
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 if that is important
or not.

I¹m going to investigate adding a map to the plugin, then add an entry for every request.

The entry will be a hash of the request and a random number.

I¹ll 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¹m not sure about the CORS issue with camera pluginŠ I¹ll 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¹m
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 random
>> 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 plugin
>> will
>> > be broken (can't use resulting URL in <img>).
>> >
>> > Although we might just do (this is different than the current mapping
>>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.org>
>> > > wrote:
>> > >
>> > > > This whole thing reeks of sadness and pain.
>> > > >
>> > > > The security implications of this will have to be considered very
>> > > > 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, for
>> > 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 method
>>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?
You
>> > 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 work
>> 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 lose
>> some
>> > > > > functionality.
>> > > > >
>> > > > > 1. No more whitelist feature (NSURLProtocol is not supported
in
>> > > > 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


Mime
View raw message