There have been major changes to the `wkwebview` branch of `cordova-ios`.
The `WKWebView` functionality has been moved to a plugin in the
`cordova-plugins` repo.
So, for now you can do:
cordova create wkwvtest test.project wkwvtest
cd wkwvtest
cordova platform add ios@wkwebview --usegit
cordova plugin add
https://github.com/apache/cordova-plugins.git#master:wkwebview-engine
Modify the root `config.xml` and edit this value to:
<content src="http://localhost:0"; />
Then:
cordova emulate
You might get a build error, this is a `plugman` bug that doesn't install
`WebKit.framework` properly even though it is defined in plugin.xml. You
might have to do a:
open -a Xcode platforms/ios
...and add the framework manually.
On Thu, Nov 6, 2014 at 11:15 AM, Shazron <shaz...@gmail.com> wrote:
> Thanks Tony - I'll look at that PR when I have some time.
>
> Yesterday I did some major work to isolate the webviews into plugins
> (CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the risk
> by extracting the WKWebView items into a plugin, and the core has no
> dependency on WebKit.framework anymore, plus speedy (well, speedier)
> updates if it needs updating. The CDVUIWebViewEngine will remain in the
> core as the default engine. I'm still working on this, but it already works
> currently. I'm abstracting things out more, and removing code from the
> CDVViewController which has become unwieldy.
>
> Swapping out engines would use the preference:
> <preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
>
> Any new web engine needs to implement the new CDVWebViewEngineProtocol
> protocol, and installed as a plugin.
>
> On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony <tony.ho...@intel.com> wrote:
>
>> I have already forked it and made the changes in a topic branch.
>> I was originally thinking that I would make 2 topic branches: 1 for
>> localhost-only and 1 for auth tokens.
>> However, after I finished the first set of changes I realized that the
>> second set would be dependent on the first.
>> I’ll submit a pull request tomorrow for you to look at - I’ll be happy to
>> redo it as multiple branches if that makes sense.
>>
>> I got a little sidetracked with local web server plugin, but I’ve also
>> forked cordova-ios and made a topic branch from wkwebview.
>> I'll start working on some of the changes I proposed earlier in this
>> thread tomorrow (for plugins like camera that return file:// urls, etc.).
>>
>> Tony
>>
>> On 11/3/14, 7:23 PM, "Shazron" <shaz...@gmail.com> wrote:
>>
>> >Thanks Tony for all the investigation. Please do fork the local web
>> server
>> >plugin and put all your work in topic branches for eventual pull requests
>> >to the main repo.
>> >
>> >This is precisely why the local web server is a plugin, and not in the
>> >core. I don't profess to be a security expert, and we can update this
>> >plugin to cover most of the security cases or someone else can provide
>> >their better plugin. I don't think this needs to be bulletproof, not that
>> >we can entirely be (has there ever been a Security Update by Apple that
>> >*didn't* include a WebKit vulnerability?)
>> >
>> >I'd like to get the cordova-ios/wkwebview branch back into the mainline
>> as
>> >soon as possible, but under an experimental flag (--experimental ?) for
>> >bin/create. This will choose a new template that has WebKit.framework in
>> >it, which will also define a macro to conditionally compile the new bits
>> >in
>> >(I haven't added the macros yet in the topic branch).
>> >
>> >
>> >
>> >
>> >On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <tony.ho...@intel.com>
>> wrote:
>> >
>> >> I spent a lot of time thinking about ways to avoid replay attacks for
>> >>the
>> >> local web server plugin this weekend.
>> >>
>> >> Specifically, I felt like there should be a way to take advantage of
>> the
>> >> fact that the client and the server are running in the same process.
>> >> I thought this might enable some kind of sideband (non-http)
>> >> authentication possibility.
>> >> The 2 possibilities I was most interested in, but eventually concluded
>> >>are
>> >> not practical were:
>> >> 1. unique token per http request - not practical because there is no
>> per
>> >> http request event available
>> >> 2. a whitelist of “remote” ports - not practical because there is no
>> >> simple way to get a list of ports in use by WKWebView
>> >>
>> >> After going down this rathole and coming up empty, I reconsidered the
>> >> original problem and came to the following conclusions.
>> >> 1. restricting requests to localhost-only limits “attacks” to
>> >>backgrounded
>> >> apps
>> >> 2. including a token in the requests will prevent backgrounded apps
>> from
>> >> being able to successfully make unwanted requests
>> >> 3. the token is vulnerable to network analysis, but that cannot be done
>> >>on
>> >> device
>> >>
>> >> Therefore, vulnerability is limited to the case where the there is
>> >> (1) a “hostile" app installed on device and running in the background
>> >>and
>> >> (2) the user’s device is connected to a wi-fi network where an attacker
>> >>is
>> >> able to perform network analysis to capture the token.
>> >> In this case, the attacker could just inspect the HTTP traffic instead
>> >>of
>> >> capturing the token and sending it to their backgrounded app.
>> >> In other words, it seems that replay attacks are possible but not
>> >>useful.
>> >> If we care about the “hostile wifi network” case, we need something
>> like
>> >> SSL.
>> >>
>> >> On 11/1/14, 4:28 PM, "Homer, Tony" <tony.ho...@intel.com> wrote:
>> >>
>> >> >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
>> >> >>>>
>> >> >>>>
>> >> >>
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> >> For additional commands, e-mail: dev-h...@cordova.apache.org
>> >>
>>
>>
>
