cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [iOS 8] WKWebView moving forward
Date Fri, 14 Nov 2014 19:15:30 GMT
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 <tommy@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 (shazron@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 <tommy@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 (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