cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tommy-carlos williams <to...@devgeeks.org>
Subject Re: [iOS 8] WKWebView moving forward
Date Mon, 10 Nov 2014 22:41:24 GMT
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 (mmocny@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 <shazron@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 <shazron@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.homer@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" <shazron@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.homer@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.homer@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.homer@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" <agrieve@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.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  
> >> >> >>>>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
 
> >> >> >>>>  
> >> >> >>>>  
> >> >> >>  
> >> >> >  
> >> >>  
> >> >>  
> >> >> ---------------------------------------------------------------------
 
> >> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org  
> >> >> For additional commands, e-mail: dev-help@cordova.apache.org  
> >> >>  
> >>  
> >>  
> >  
>  

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message