I started looking at how to make the camera plugin be able to work in WKWebView. Before, I had mentioned intercepting resource requests as a way to fix the file:// requests. However, WKWebView does not offer a way to intercept resource requests so that won’t work. :/
Andrew had suggested introducing some proxy paths as a way to deal with the path problems, which seems fine. On the other hand, the request handlers could just inspect the path in the request and do the right thing - are the proxy paths needed? I think implicit in those comments was a suggestion that the affected plugins such as camera could return URLs using those paths. The thing about changing camera and file plugins to support localhost that bothers me, is that now those core plugins effectively support a non-core plugin. Also, other (on-cordova) plugins that depend on file protocol will be incompatible with the local web server wkwebview solution (unless they make changes to support it). I wonder if it would be better to handle this in CDVPluginResult? A hook could be added to initWithStatus and exposed to plugins. Then the SALocalWebServer plugin can use the hook to inspect the message and fix it, if it is a file:// URL. So, for example, when camera calls CDVPluginResult resultWithStatus:messageAsString and passes in a file URL, SALocalServer can get a chance to inspect and modify the result – changing it to an http:localhost URL. It could simply replace the file protocol with http://localhost:port, then the handler could decode the path before building the response. This is ugly, but it would prevent the need to change the camera and file and should allow other non-cordova plugins that depend on file:// URLs to work. Tony On 10/31/14, 2:03 PM, "Homer, Tony" <tony.ho...@intel.com> wrote: >I started with cookies in my POC, but I was concerned about replay >attacks. >I couldn’t think of a way to avoid replay vulnerability with cookies >(without SSL), so I was going to switch to the side channel approach I >tried to describe. Do you think replay vulnerability is irrelevant? I’m >not a security guy, so I wasn’t sure if it mattered or not. That’s >actually one of the things I was hoping to get feedback about. > >I guess I don’t follow how CORS relates to the camera plugin, does it use >XHR? Maybe you can elaborate? >I expect I’ll see it when I try the camera plugin from WKWebView, just >didn’t get around to it yet. >The only thing that jumps out at me is that you get a file:// url back - >we could change that. >Or maybe intercept file:// requests in the plugin? If it’s just a path >problem, maybe we could intercept the request, fix the path, then respond >with the right thing... > >Tony > >On 10/31/14, 1:19 PM, "Andrew Grieve" <agri...@chromium.org> wrote: > >>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.sh...@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.ho...@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" <agri...@chromium.org> wrote: >>> >>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <shaz...@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 >>><agri...@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 <shaz...@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 >>><to...@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" <shaz...@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-unsubscr...@cordova.apache.org >>> For additional commands, e-mail: dev-h...@cordova.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> For additional commands, e-mail: dev-h...@cordova.apache.org >>> >>> >
