Update: Xcode 6.1.1 GM seed (Nov 14th 2014) does not include the "loadFileURL:readAccessURL:" selector in the WKWebView.h header. So the bug fix we are waiting for most likely won't be in iOS 8.1.1
On Mon, Nov 10, 2014 at 3:30 PM, tommy-carlos williams <to...@devgeeks.org> wrote: > Yeah… I’ll try to report some of it and get back to you. > > -- > tommy-carlos williams > > On 11 November 2014 at 09:50:55, Shazron (shaz...@gmail.com) wrote: > > Bug report? Or email me personally. Which ones besides the ones that will > have problems as we discussed on this thread. > > On Mon, Nov 10, 2014 at 2:41 PM, tommy-carlos williams <to...@devgeeks.org > > > wrote: > > > I had much less success… it doesn’t play well with other legacy plugins, > > does it? > > > > > > > > -- > > tommy-carlos williams > > > > On 11 November 2014 at 03:00:30, Michal Mocny (mmo...@chromium.org) > wrote: > > > > Success! I did indeed have to add the framework manually. > > > > Thanks for instructions. > > > > On Thu, Nov 6, 2014 at 7:49 PM, Shazron <shaz...@gmail.com> wrote: > > > > > 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 > > > >> >> > > > >> > > > >> > > > > > > > > > >
