You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@apache.org> on 2014/10/29 22:39:35 UTC
[iOS 8] WKWebView moving forward
## 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)
Re: [iOS 8] WKWebView moving forward
Posted by Kerri Shotts <ke...@photokandy.com>.
le *sigh* :-(
___________________________________
*Kerri Shotts*
photoKandy Studios, LLC
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
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 (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 <sh...@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 <sh...@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 <to...@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" <sh...@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 <to...@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" <to...@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" <to...@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" <ag...@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
> > > >> >> >>>><ag...@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
> > > >> >>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by tommy-carlos williams <to...@devgeeks.org>.
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 <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 (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 <sh...@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 <sh...@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 <to...@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" <sh...@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 <to...@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" <to...@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" <to...@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" <ag...@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" <ag...@chromium.org>
> > >> wrote:
> > >> >> >>>>
> > >> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
> > >> >> >>>><ag...@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" <sh...@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
> > >> >>
> > >>
> > >>
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
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 (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 <sh...@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 <sh...@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 <to...@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" <sh...@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 <to...@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" <to...@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" <to...@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" <ag...@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" <ag...@chromium.org>
> > >> wrote:
> > >> >> >>>>
> > >> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
> > >> >> >>>><ag...@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" <sh...@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
> > >> >>
> > >>
> > >>
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by tommy-carlos williams <to...@devgeeks.org>.
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 <sh...@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 <sh...@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 <to...@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" <sh...@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 <to...@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" <to...@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" <to...@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" <ag...@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" <ag...@chromium.org>
> >> wrote:
> >> >> >>>>
> >> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
> >> >> >>>><ag...@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" <sh...@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
> >> >>
> >>
> >>
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Michal Mocny <mm...@chromium.org>.
Success! I did indeed have to add the framework manually.
Thanks for instructions.
On Thu, Nov 6, 2014 at 7:49 PM, Shazron <sh...@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 <sh...@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 <to...@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" <sh...@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 <to...@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" <to...@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" <to...@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" <ag...@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" <ag...@chromium.org>
> >> wrote:
> >> >> >>>>
> >> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
> >> >> >>>><ag...@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" <sh...@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
> >> >>
> >>
> >>
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
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 <sh...@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 <to...@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" <sh...@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 <to...@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" <to...@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" <to...@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" <ag...@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" <ag...@chromium.org>
>> wrote:
>> >> >>>>
>> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
>> >> >>>><ag...@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 <sh...@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" <sh...@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
>> >>
>>
>>
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
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 <to...@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" <sh...@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 <to...@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" <to...@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" <to...@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" <ag...@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" <ag...@chromium.org>
> wrote:
> >> >>>>
> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
> >> >>>><ag...@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 <sh...@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" <sh...@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
> >>
>
>
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
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" <sh...@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 <to...@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" <to...@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" <to...@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" <ag...@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" <ag...@chromium.org> wrote:
>> >>>>
>> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
>> >>>><ag...@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 <sh...@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" <sh...@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
>>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
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 <to...@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" <to...@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" <to...@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" <ag...@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" <ag...@chromium.org> wrote:
> >>>>
> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
> >>>><ag...@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 <sh...@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" <sh...@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
>
Re: [iOS 8] WKWebView moving forward
Posted by Michal Mocny <mm...@chromium.org>.
Awesome analysis Tony, thanks for the efforts & the great summary.
On Mon, Nov 3, 2014 at 10:27 AM, Homer, Tony <to...@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" <to...@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" <to...@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" <ag...@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" <ag...@chromium.org> wrote:
> >>>>
> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
> >>>><ag...@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 <sh...@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" <sh...@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
>
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
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" <to...@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" <to...@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" <ag...@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" <ag...@chromium.org> wrote:
>>>>
>>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
>>>><ag...@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 <sh...@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" <sh...@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
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
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" <to...@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" <ag...@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" <ag...@chromium.org> wrote:
>>>
>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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
>>><ag...@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 <sh...@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" <sh...@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
>>>
>>>
>
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
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" <ag...@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" <ag...@chromium.org> wrote:
>>
>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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 <ag...@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 <sh...@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" <sh...@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
>>
>>
Re: [iOS 8] WKWebView moving forward
Posted by Andrew Grieve <ag...@chromium.org>.
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" <ag...@chromium.org> wrote:
>
> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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 <ag...@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 <sh...@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" <sh...@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
>
>
RE: [iOS 8] WKWebView moving forward
Posted by "Kirk Shoop (MS OPEN TECH)" <Ki...@microsoft.com>.
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" <ag...@chromium.org> wrote:
>On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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 <ag...@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 <sh...@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" <sh...@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
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
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" <ag...@chromium.org> wrote:
>On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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 <ag...@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 <sh...@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" <sh...@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
Re: [iOS 8] WKWebView moving forward
Posted by Andrew Grieve <ag...@chromium.org>.
On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@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 <ag...@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 <sh...@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" <sh...@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)
> > > > >
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
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
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.
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 <ag...@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 <sh...@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" <sh...@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)
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Andrew Grieve <ag...@chromium.org>.
The reason I think it's the wrong way around is that: What if other plugins
want to work with localwebserver? Does each plugin wanting to work with it
send a PR to localwebserver for it to add a category to them?
On Tue, Nov 18, 2014 at 10:59 AM, Jesse <pu...@gmail.com> wrote:
> Shaz's solution has less impact and seems more elegant.
>
> // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>
> If no-one ( generically ) has provided the nativeFullPath method, then use
> it as is, otherwise call it.
> No need for any (direct) dependency between File + LocalServer.
>
> @purplecabbage
> risingj.com
>
> On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Having the localserver plugin add behaviour to file plugin feels like the
> > dependency is in the wrong direction to me.
> >
> > How about having CDVFile.m do something like:
> >
> > CDVPlugin* p = [commandDelegate getCommandInstance:@"LocalServer"];
> > if (p != nil) {
> > nativeURL = [p transformURL:nativeURL]; // do some local declaration to
> > make this not complain about unrecognized selector
> > }
> >
> > Would probably also need an "untransformURL" to go the other direction as
> > well.
> >
> > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com> wrote:
> >
> > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
> > > included.
> > >
> > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > > > Sorry I should have looked into the File API code first (no
> JavaScript
> > > > changes, that would not work).
> > > >
> > > > Essentially I need to "override" this line from my plugin:
> > > >
> > >
> >
> https://github.com/apache/cordova-plugin-file/blob/82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/CDVAssetLibraryFilesystem.m#L74
> > > > (plus the CDVLocalFileSystem equivalent).
> > > >
> > > > Since Obj-C categories can't really "override" methods (behavior
> > > > undefined), and I don't want to do some runtime swap implementation
> > > voodoo,
> > > > I would replace the line above with something like:
> > > >
> > > > NSString* nativeURL = [NSString stringWithFormat:@
> > > > "assets-library:/%@",fullPath];
> > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) { // some
> > > > unique selector name perhaps
> > > > nativeURL = [self nativeFullPath:fullPath]; // this code won't
> > > > compile, pseudo-code for now. Will call my category method defined in
> > my
> > > > plugin for CDVAssetLibraryFileSystem
> > > > }
> > > > dirEntry[@"nativeURL"] = nativeURL;
> > > >
> > > > Backwards compatible.
> > > >
> > > >
> > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com> wrote:
> > > >
> > > >> Local Web Server Checklist:
> > > >> 1. We have random port usage
> > > >> 2. We have the token/cookie check
> > > >> 3. We have the localhost check
> > > >> 4. The app is now installed under http://localhost:RANDOM_PORT/www/
> > > >>
> > > >> It'll be easy (relatively) to add support for:
> > > >> http://localhost:RANDOM_PORT/asset-library/
> > > >> http://localhost:RANDOM_PORT/file-system/
> > > >>
> > > >> The only issue now is changing FileEntry.toURL(). I'm thinking of
> some
> > > >> runtime 'magic' in the local web server where it detects the File
> > > plugin,
> > > >> and change the implementation of FileEntry.toURL() (or through
> > injecting
> > > >> JavaScript, probably easier).
> > > >>
> > > >>
> > > >> 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 <sh...@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" <sh...@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)
> > > >>> > > >
> > > >>> > >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Tommy Williams <to...@devgeeks.org>.
Whew :)
On 21/11/2014 12:58 am, "Homer, Tony" <to...@intel.com> wrote:
> Thanks for asking, Tommy. Shazron’s original security caveat was:
> "Any backgrounded app can potentially access this local web server when
> your app is running.”
>
> My PR made 2 changes:
> 1. restrict requests to localhost
> 2. provide for and require that a security token be included in the request
>
> I needed to update the security caveat as part of the PR, but I didn’t
> want to oversell the fix!
> Up until now, I thought localhost packets worked just like any other
> packets and would be visible to a network sniffer.
> However, after reading your question and doing a little searching, it
> seems that is incorrect.
> From http://en.wikipedia.org/wiki/Localhost#Name_resolution:
>
> "The processing of any packets sent to a loopback address is implemented
> in the link layer of the TCP/IP stack. Such packets are never delivered to
> any network interface controller (NIC) or device driver"
>
> I guess we can drop that sentence from the security caveat.
> I’ll submit a PR.
>
> Tony
>
> On 11/19/14, 7:30 PM, "Shazron" <sh...@gmail.com> wrote:
>
> >I'm not sure - Tony wrote that part maybe he can explain the intricacies.
> >
> >On Wed, Nov 19, 2014 at 4:23 PM, tommy-carlos williams
> ><to...@devgeeks.org>
> >wrote:
> >
> >> Shazron,
> >>
> >> I just noticed this in the README for the plugin:
> >>
> >> "However, since requests are made over http, your app's activity may be
> >> visible to others on the name wi-fi network.”
> >>
> >> Is this actually true? Why would traffic to localhost leave the device
> >>and
> >> be visible over the wifi?
> >>
> >>
> >>
> >> --
> >> tommy-carlos williams
> >>
> >> On 20 November 2014 at 08:18:28, Homer, Tony (tony.homer@intel.com)
> >>wrote:
> >>
> >> Ugh. Thanks for the additional information, Shazron.
> >>
> >> I had previously proposed adding a hook (by which I meant a delegate
> >> method) to CDVPluginResult (that would be called from -
> >> (CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
> >> message:(id)theMessage) so that LocalWebServer could (blindly) detect
> >>and
> >> transform urls.
> >>
> >> It seems like it would help with this case, but not be generally useful
> >> for anything else…
> >>
> >> Tony
> >>
> >> On 11/19/14, 3:23 PM, "Shazron" <sh...@gmail.com> wrote:
> >>
> >> >Ideally a general solution like you proposed should work, but I forgot
> >>to
> >> >mention that in this case, since we are talking about WKWebView, we
> >>can't
> >> >use NSURLProtocol since it is not supported in that framework [1][2]
> >> >
> >> >The only other general way I can see is to require explicit support in
> >> >plugins, they may have to call something in the
> >> >commandDelegate/viewController to transform a url, that can be set by
> >> >another plugin, in this case LocalWebServer (my revised proposal was a
> >> >'push' this is a 'pull').
> >> >
> >> >
> >> >[1] https://issues.apache.org/jira/browse/CB-7049
> >> >[2] http://www.openradar.me/18492325
> >> >
> >> >On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com>
> >> >wrote:
> >> >
> >> >> If we are just talking about CB-8032, then I can see that this
> >>approach
> >> >>is
> >> >> cleaner for the file plugin.
> >> >>
> >> >> Regarding local web server plugin in general - what about other
> >>plugins
> >> >> such as camera?
> >> >> Doesn¹t there need to be a general solution that will provide
> >> >> compatibility between local web server plugin and any plugin that
> >> >>returns
> >> >> a file protocol URL?
> >> >>
> >> >> Tony
> >> >>
> >> >> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
> >> >>
> >> >> >I commented on Ian's comment on CB-8032:
> >> >> >
> >> >>
> >> >>
> >>
> >>
> https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p
> >> >>a
> >> >>
> >>
> >>>>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#co
> >>>>>mm
> >> >>>en
> >> >> >t-14216403
> >> >> >
> >> >> >My goal was to have a loose coupling of this functionality (CDVFile
> >> >>need
> >> >> >not know about LocalWebServer at all) -- and Ian's comment of this
> >> >>change
> >> >> >is that would impact all CDVFileSystem instances makes this not an
> >> >>ideal
> >> >> >solution, what if you have two Cordova WebView instances, etc.
> >> >> >
> >> >> >My revised proposal requires CDVFileSystem to have a delegate that
> >>can
> >> >>be
> >> >> >set. Any class can set it to override the nativeURL behaviour, and
> >> >> >CDVFileSystem will call this method in the delegate if available. It
> >> >> >achieves the same goal without the potentially undefined behaviour
> >>of
> >> >>an
> >> >> >Obj-C Category.
> >> >> >
> >> >> >The LocalWebServer gets the currently installed File plugin,
> >>enumerates
> >> >> >all
> >> >> >available filesystems, and sets this delegate on each, to its own
> >> >> >implementation.
> >> >> >
> >> >> >Tony - I think this is approach is cleaner, and is more
> >>maintainable.
> >> >> >
> >> >> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland
> >><ic...@chromium.org>
> >> >> >wrote:
> >> >> >
> >> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com>
> >> >>wrote:
> >> >> >>
> >> >> >> > Shaz's solution has less impact and seems more elegant.
> >> >> >> >
> >> >> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
> >> >> >> >
> >> >> >> > If no-one ( generically ) has provided the nativeFullPath
> >>method,
> >> >>then
> >> >> >> use
> >> >> >> > it as is, otherwise call it.
> >> >> >> > No need for any (direct) dependency between File + LocalServer.
> >> >> >> >
> >> >> >>
> >> >> >> My first instinct, looking at the code, was that it was wrong,
> >> >>exactly
> >> >> >> because there *is* a dependency. You don't normally add code to a
> >> >>base
> >> >> >> class to change its behaviour when there is a category defined on
> >>it.
> >> >> >> Normally that goes the other way: when you add a category to a
> >>base
> >> >> >>class,
> >> >> >> all of the code that's relevant to that category is *in the
> >> >>category*,
> >> >> >>and
> >> >> >> the base class needs to know nothing at all about it, including
> >>its
> >> >> >> existence.
> >> >> >>
> >> >> >> As I said in the PR, it may be that this really is the cleanest
> >>and
> >> >>best
> >> >> >> way to go forward with this; I just wanted to have this discussion
> >> >>and
> >> >> >> figure it out with the community before committing to any
> >> >> >> hard-to-change-later technical debt. It does become an API
> >>surface,
> >> >>and
> >> >> >>we
> >> >> >> will have to maintain whatever we adopt.
> >> >> >>
> >> >> >> Ian
> >> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> > @purplecabbage
> >> >> >> > risingj.com
> >> >> >> >
> >> >> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
> >> >><agrieve@chromium.org
> >> >> >
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> > > Having the localserver plugin add behaviour to file plugin
> >>feels
> >> >> >>like
> >> >> >> the
> >> >> >> > > dependency is in the wrong direction to me.
> >> >> >> > >
> >> >> >> > > How about having CDVFile.m do something like:
> >> >> >> > >
> >> >> >> > > CDVPlugin* p = [commandDelegate
> >> >>getCommandInstance:@"LocalServer"];
> >> >> >> > > if (p != nil) {
> >> >> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
> >> >> >>declaration
> >> >> >> to
> >> >> >> > > make this not complain about unrecognized selector
> >> >> >> > > }
> >> >> >> > >
> >> >> >> > > Would probably also need an "untransformURL" to go the other
> >> >> >>direction
> >> >> >> as
> >> >> >> > > well.
> >> >> >> > >
> >> >> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com>
> >> >> wrote:
> >> >> >> > >
> >> >> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with
> >>pull
> >> >> >> request
> >> >> >> > > > included.
> >> >> >> > > >
> >> >> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <shazron@gmail.com
> >
> >> >> >>wrote:
> >> >> >> > > >
> >> >> >> > > > > Sorry I should have looked into the File API code first
> >>(no
> >> >> >> > JavaScript
> >> >> >> > > > > changes, that would not work).
> >> >> >> > > > >
> >> >> >> > > > > Essentially I need to "override" this line from my plugin:
> >> >> >> > > > >
> >> >> >> > > >
> >> >> >> > > https://github.com/apache/cordova-plugin-file/blob/
> >> >> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
> >> >> >> > CDVAssetLibraryFilesystem.m#L74
> >> >> >> > > > > (plus the CDVLocalFileSystem equivalent).
> >> >> >> > > > >
> >> >> >> > > > > Since Obj-C categories can't really "override" methods
> >> >>(behavior
> >> >> >> > > > > undefined), and I don't want to do some runtime swap
> >> >> >>implementation
> >> >> >> > > > voodoo,
> >> >> >> > > > > I would replace the line above with something like:
> >> >> >> > > > >
> >> >> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
> >> >> >> > > > > "assets-library:/%@",fullPath];
> >> >> >> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)])
> >>{
> >> >>//
> >> >> >> some
> >> >> >> > > > > unique selector name perhaps
> >> >> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this code
> >> >> >>won't
> >> >> >> > > > > compile, pseudo-code for now. Will call my category method
> >> >> >>defined
> >> >> >> in
> >> >> >> > > my
> >> >> >> > > > > plugin for CDVAssetLibraryFileSystem
> >> >> >> > > > > }
> >> >> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
> >> >> >> > > > >
> >> >> >> > > > > Backwards compatible.
> >> >> >> > > > >
> >> >> >> > > > >
> >> >> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron
> >><sh...@gmail.com>
> >> >> >> wrote:
> >> >> >> > > > >
> >> >> >> > > > >> Local Web Server Checklist:
> >> >> >> > > > >> 1. We have random port usage
> >> >> >> > > > >> 2. We have the token/cookie check
> >> >> >> > > > >> 3. We have the localhost check
> >> >> >> > > > >> 4. The app is now installed under
> >> >>http://localhost:RANDOM_PORT
> >> >> >> /www/
> >> >> >> > > > >>
> >> >> >> > > > >> It'll be easy (relatively) to add support for:
> >> >> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
> >> >> >> > > > >> http://localhost:RANDOM_PORT/file-system/
> >> >> >> > > > >>
> >> >> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm
> >> >>thinking
> >> >> >>of
> >> >> >> > some
> >> >> >> > > > >> runtime 'magic' in the local web server where it detects
> >>the
> >> >> >>File
> >> >> >> > > > plugin,
> >> >> >> > > > >> and change the implementation of FileEntry.toURL() (or
> >> >>through
> >> >> >> > > injecting
> >> >> >> > > > >> JavaScript, probably easier).
> >> >> >> > > > >>
> >> >> >> > > > >>
> >> >> >> > > > >> 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
> >> >><sh...@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
> >> >>
> >> >>
> >>
> >>
> >>B?KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB?
> >> ? [??X?昧?X?K K[XZ[ ? ]?][??X?昧?X?P 白? ??K?\ X? K????B???? Y ] [??[
> >> 栢[X[? ? K[XZ[ ? ]?Z [ 白? ??K?\ X? K????B
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
Thanks for asking, Tommy. Shazron’s original security caveat was:
"Any backgrounded app can potentially access this local web server when
your app is running.”
My PR made 2 changes:
1. restrict requests to localhost
2. provide for and require that a security token be included in the request
I needed to update the security caveat as part of the PR, but I didn’t
want to oversell the fix!
Up until now, I thought localhost packets worked just like any other
packets and would be visible to a network sniffer.
However, after reading your question and doing a little searching, it
seems that is incorrect.
From http://en.wikipedia.org/wiki/Localhost#Name_resolution:
"The processing of any packets sent to a loopback address is implemented
in the link layer of the TCP/IP stack. Such packets are never delivered to
any network interface controller (NIC) or device driver"
I guess we can drop that sentence from the security caveat.
I’ll submit a PR.
Tony
On 11/19/14, 7:30 PM, "Shazron" <sh...@gmail.com> wrote:
>I'm not sure - Tony wrote that part maybe he can explain the intricacies.
>
>On Wed, Nov 19, 2014 at 4:23 PM, tommy-carlos williams
><to...@devgeeks.org>
>wrote:
>
>> Shazron,
>>
>> I just noticed this in the README for the plugin:
>>
>> "However, since requests are made over http, your app's activity may be
>> visible to others on the name wi-fi network.”
>>
>> Is this actually true? Why would traffic to localhost leave the device
>>and
>> be visible over the wifi?
>>
>>
>>
>> --
>> tommy-carlos williams
>>
>> On 20 November 2014 at 08:18:28, Homer, Tony (tony.homer@intel.com)
>>wrote:
>>
>> Ugh. Thanks for the additional information, Shazron.
>>
>> I had previously proposed adding a hook (by which I meant a delegate
>> method) to CDVPluginResult (that would be called from -
>> (CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
>> message:(id)theMessage) so that LocalWebServer could (blindly) detect
>>and
>> transform urls.
>>
>> It seems like it would help with this case, but not be generally useful
>> for anything else…
>>
>> Tony
>>
>> On 11/19/14, 3:23 PM, "Shazron" <sh...@gmail.com> wrote:
>>
>> >Ideally a general solution like you proposed should work, but I forgot
>>to
>> >mention that in this case, since we are talking about WKWebView, we
>>can't
>> >use NSURLProtocol since it is not supported in that framework [1][2]
>> >
>> >The only other general way I can see is to require explicit support in
>> >plugins, they may have to call something in the
>> >commandDelegate/viewController to transform a url, that can be set by
>> >another plugin, in this case LocalWebServer (my revised proposal was a
>> >'push' this is a 'pull').
>> >
>> >
>> >[1] https://issues.apache.org/jira/browse/CB-7049
>> >[2] http://www.openradar.me/18492325
>> >
>> >On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com>
>> >wrote:
>> >
>> >> If we are just talking about CB-8032, then I can see that this
>>approach
>> >>is
>> >> cleaner for the file plugin.
>> >>
>> >> Regarding local web server plugin in general - what about other
>>plugins
>> >> such as camera?
>> >> Doesn¹t there need to be a general solution that will provide
>> >> compatibility between local web server plugin and any plugin that
>> >>returns
>> >> a file protocol URL?
>> >>
>> >> Tony
>> >>
>> >> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
>> >>
>> >> >I commented on Ian's comment on CB-8032:
>> >> >
>> >>
>> >>
>>
>>https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p
>> >>a
>> >>
>>
>>>>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#co
>>>>>mm
>> >>>en
>> >> >t-14216403
>> >> >
>> >> >My goal was to have a loose coupling of this functionality (CDVFile
>> >>need
>> >> >not know about LocalWebServer at all) -- and Ian's comment of this
>> >>change
>> >> >is that would impact all CDVFileSystem instances makes this not an
>> >>ideal
>> >> >solution, what if you have two Cordova WebView instances, etc.
>> >> >
>> >> >My revised proposal requires CDVFileSystem to have a delegate that
>>can
>> >>be
>> >> >set. Any class can set it to override the nativeURL behaviour, and
>> >> >CDVFileSystem will call this method in the delegate if available. It
>> >> >achieves the same goal without the potentially undefined behaviour
>>of
>> >>an
>> >> >Obj-C Category.
>> >> >
>> >> >The LocalWebServer gets the currently installed File plugin,
>>enumerates
>> >> >all
>> >> >available filesystems, and sets this delegate on each, to its own
>> >> >implementation.
>> >> >
>> >> >Tony - I think this is approach is cleaner, and is more
>>maintainable.
>> >> >
>> >> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland
>><ic...@chromium.org>
>> >> >wrote:
>> >> >
>> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com>
>> >>wrote:
>> >> >>
>> >> >> > Shaz's solution has less impact and seems more elegant.
>> >> >> >
>> >> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>> >> >> >
>> >> >> > If no-one ( generically ) has provided the nativeFullPath
>>method,
>> >>then
>> >> >> use
>> >> >> > it as is, otherwise call it.
>> >> >> > No need for any (direct) dependency between File + LocalServer.
>> >> >> >
>> >> >>
>> >> >> My first instinct, looking at the code, was that it was wrong,
>> >>exactly
>> >> >> because there *is* a dependency. You don't normally add code to a
>> >>base
>> >> >> class to change its behaviour when there is a category defined on
>>it.
>> >> >> Normally that goes the other way: when you add a category to a
>>base
>> >> >>class,
>> >> >> all of the code that's relevant to that category is *in the
>> >>category*,
>> >> >>and
>> >> >> the base class needs to know nothing at all about it, including
>>its
>> >> >> existence.
>> >> >>
>> >> >> As I said in the PR, it may be that this really is the cleanest
>>and
>> >>best
>> >> >> way to go forward with this; I just wanted to have this discussion
>> >>and
>> >> >> figure it out with the community before committing to any
>> >> >> hard-to-change-later technical debt. It does become an API
>>surface,
>> >>and
>> >> >>we
>> >> >> will have to maintain whatever we adopt.
>> >> >>
>> >> >> Ian
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > @purplecabbage
>> >> >> > risingj.com
>> >> >> >
>> >> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
>> >><agrieve@chromium.org
>> >> >
>> >> >> > wrote:
>> >> >> >
>> >> >> > > Having the localserver plugin add behaviour to file plugin
>>feels
>> >> >>like
>> >> >> the
>> >> >> > > dependency is in the wrong direction to me.
>> >> >> > >
>> >> >> > > How about having CDVFile.m do something like:
>> >> >> > >
>> >> >> > > CDVPlugin* p = [commandDelegate
>> >>getCommandInstance:@"LocalServer"];
>> >> >> > > if (p != nil) {
>> >> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
>> >> >>declaration
>> >> >> to
>> >> >> > > make this not complain about unrecognized selector
>> >> >> > > }
>> >> >> > >
>> >> >> > > Would probably also need an "untransformURL" to go the other
>> >> >>direction
>> >> >> as
>> >> >> > > well.
>> >> >> > >
>> >> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com>
>> >> wrote:
>> >> >> > >
>> >> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with
>>pull
>> >> >> request
>> >> >> > > > included.
>> >> >> > > >
>> >> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com>
>> >> >>wrote:
>> >> >> > > >
>> >> >> > > > > Sorry I should have looked into the File API code first
>>(no
>> >> >> > JavaScript
>> >> >> > > > > changes, that would not work).
>> >> >> > > > >
>> >> >> > > > > Essentially I need to "override" this line from my plugin:
>> >> >> > > > >
>> >> >> > > >
>> >> >> > > https://github.com/apache/cordova-plugin-file/blob/
>> >> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
>> >> >> > CDVAssetLibraryFilesystem.m#L74
>> >> >> > > > > (plus the CDVLocalFileSystem equivalent).
>> >> >> > > > >
>> >> >> > > > > Since Obj-C categories can't really "override" methods
>> >>(behavior
>> >> >> > > > > undefined), and I don't want to do some runtime swap
>> >> >>implementation
>> >> >> > > > voodoo,
>> >> >> > > > > I would replace the line above with something like:
>> >> >> > > > >
>> >> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
>> >> >> > > > > "assets-library:/%@",fullPath];
>> >> >> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)])
>>{
>> >>//
>> >> >> some
>> >> >> > > > > unique selector name perhaps
>> >> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this code
>> >> >>won't
>> >> >> > > > > compile, pseudo-code for now. Will call my category method
>> >> >>defined
>> >> >> in
>> >> >> > > my
>> >> >> > > > > plugin for CDVAssetLibraryFileSystem
>> >> >> > > > > }
>> >> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
>> >> >> > > > >
>> >> >> > > > > Backwards compatible.
>> >> >> > > > >
>> >> >> > > > >
>> >> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron
>><sh...@gmail.com>
>> >> >> wrote:
>> >> >> > > > >
>> >> >> > > > >> Local Web Server Checklist:
>> >> >> > > > >> 1. We have random port usage
>> >> >> > > > >> 2. We have the token/cookie check
>> >> >> > > > >> 3. We have the localhost check
>> >> >> > > > >> 4. The app is now installed under
>> >>http://localhost:RANDOM_PORT
>> >> >> /www/
>> >> >> > > > >>
>> >> >> > > > >> It'll be easy (relatively) to add support for:
>> >> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
>> >> >> > > > >> http://localhost:RANDOM_PORT/file-system/
>> >> >> > > > >>
>> >> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm
>> >>thinking
>> >> >>of
>> >> >> > some
>> >> >> > > > >> runtime 'magic' in the local web server where it detects
>>the
>> >> >>File
>> >> >> > > > plugin,
>> >> >> > > > >> and change the implementation of FileEntry.toURL() (or
>> >>through
>> >> >> > > injecting
>> >> >> > > > >> JavaScript, probably easier).
>> >> >> > > > >>
>> >> >> > > > >>
>> >> >> > > > >> 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
>> >><sh...@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" <sh...@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
>> >>
>> >>
>>
>>
>>B?KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB?
>> ? [??X?昧?X?K K[XZ[ ? ]?][??X?昧?X?P 白? ??K?\ X? K????B???? Y ] [??[
>> 栢[X[? ? K[XZ[ ? ]?Z [ 白? ??K?\ X? K????B
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
I'm not sure - Tony wrote that part maybe he can explain the intricacies.
On Wed, Nov 19, 2014 at 4:23 PM, tommy-carlos williams <to...@devgeeks.org>
wrote:
> Shazron,
>
> I just noticed this in the README for the plugin:
>
> "However, since requests are made over http, your app's activity may be
> visible to others on the name wi-fi network.”
>
> Is this actually true? Why would traffic to localhost leave the device and
> be visible over the wifi?
>
>
>
> --
> tommy-carlos williams
>
> On 20 November 2014 at 08:18:28, Homer, Tony (tony.homer@intel.com) wrote:
>
> Ugh. Thanks for the additional information, Shazron.
>
> I had previously proposed adding a hook (by which I meant a delegate
> method) to CDVPluginResult (that would be called from -
> (CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
> message:(id)theMessage) so that LocalWebServer could (blindly) detect and
> transform urls.
>
> It seems like it would help with this case, but not be generally useful
> for anything else…
>
> Tony
>
> On 11/19/14, 3:23 PM, "Shazron" <sh...@gmail.com> wrote:
>
> >Ideally a general solution like you proposed should work, but I forgot to
> >mention that in this case, since we are talking about WKWebView, we can't
> >use NSURLProtocol since it is not supported in that framework [1][2]
> >
> >The only other general way I can see is to require explicit support in
> >plugins, they may have to call something in the
> >commandDelegate/viewController to transform a url, that can be set by
> >another plugin, in this case LocalWebServer (my revised proposal was a
> >'push' this is a 'pull').
> >
> >
> >[1] https://issues.apache.org/jira/browse/CB-7049
> >[2] http://www.openradar.me/18492325
> >
> >On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com>
> >wrote:
> >
> >> If we are just talking about CB-8032, then I can see that this approach
> >>is
> >> cleaner for the file plugin.
> >>
> >> Regarding local web server plugin in general - what about other plugins
> >> such as camera?
> >> Doesn¹t there need to be a general solution that will provide
> >> compatibility between local web server plugin and any plugin that
> >>returns
> >> a file protocol URL?
> >>
> >> Tony
> >>
> >> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
> >>
> >> >I commented on Ian's comment on CB-8032:
> >> >
> >>
> >>
> https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p
> >>a
> >>
> >>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
> >>>en
> >> >t-14216403
> >> >
> >> >My goal was to have a loose coupling of this functionality (CDVFile
> >>need
> >> >not know about LocalWebServer at all) -- and Ian's comment of this
> >>change
> >> >is that would impact all CDVFileSystem instances makes this not an
> >>ideal
> >> >solution, what if you have two Cordova WebView instances, etc.
> >> >
> >> >My revised proposal requires CDVFileSystem to have a delegate that can
> >>be
> >> >set. Any class can set it to override the nativeURL behaviour, and
> >> >CDVFileSystem will call this method in the delegate if available. It
> >> >achieves the same goal without the potentially undefined behaviour of
> >>an
> >> >Obj-C Category.
> >> >
> >> >The LocalWebServer gets the currently installed File plugin, enumerates
> >> >all
> >> >available filesystems, and sets this delegate on each, to its own
> >> >implementation.
> >> >
> >> >Tony - I think this is approach is cleaner, and is more maintainable.
> >> >
> >> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <ic...@chromium.org>
> >> >wrote:
> >> >
> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com>
> >>wrote:
> >> >>
> >> >> > Shaz's solution has less impact and seems more elegant.
> >> >> >
> >> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
> >> >> >
> >> >> > If no-one ( generically ) has provided the nativeFullPath method,
> >>then
> >> >> use
> >> >> > it as is, otherwise call it.
> >> >> > No need for any (direct) dependency between File + LocalServer.
> >> >> >
> >> >>
> >> >> My first instinct, looking at the code, was that it was wrong,
> >>exactly
> >> >> because there *is* a dependency. You don't normally add code to a
> >>base
> >> >> class to change its behaviour when there is a category defined on it.
> >> >> Normally that goes the other way: when you add a category to a base
> >> >>class,
> >> >> all of the code that's relevant to that category is *in the
> >>category*,
> >> >>and
> >> >> the base class needs to know nothing at all about it, including its
> >> >> existence.
> >> >>
> >> >> As I said in the PR, it may be that this really is the cleanest and
> >>best
> >> >> way to go forward with this; I just wanted to have this discussion
> >>and
> >> >> figure it out with the community before committing to any
> >> >> hard-to-change-later technical debt. It does become an API surface,
> >>and
> >> >>we
> >> >> will have to maintain whatever we adopt.
> >> >>
> >> >> Ian
> >> >>
> >> >>
> >> >> >
> >> >> > @purplecabbage
> >> >> > risingj.com
> >> >> >
> >> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
> >><agrieve@chromium.org
> >> >
> >> >> > wrote:
> >> >> >
> >> >> > > Having the localserver plugin add behaviour to file plugin feels
> >> >>like
> >> >> the
> >> >> > > dependency is in the wrong direction to me.
> >> >> > >
> >> >> > > How about having CDVFile.m do something like:
> >> >> > >
> >> >> > > CDVPlugin* p = [commandDelegate
> >>getCommandInstance:@"LocalServer"];
> >> >> > > if (p != nil) {
> >> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
> >> >>declaration
> >> >> to
> >> >> > > make this not complain about unrecognized selector
> >> >> > > }
> >> >> > >
> >> >> > > Would probably also need an "untransformURL" to go the other
> >> >>direction
> >> >> as
> >> >> > > well.
> >> >> > >
> >> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com>
> >> wrote:
> >> >> > >
> >> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
> >> >> request
> >> >> > > > included.
> >> >> > > >
> >> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com>
> >> >>wrote:
> >> >> > > >
> >> >> > > > > Sorry I should have looked into the File API code first (no
> >> >> > JavaScript
> >> >> > > > > changes, that would not work).
> >> >> > > > >
> >> >> > > > > Essentially I need to "override" this line from my plugin:
> >> >> > > > >
> >> >> > > >
> >> >> > > https://github.com/apache/cordova-plugin-file/blob/
> >> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
> >> >> > CDVAssetLibraryFilesystem.m#L74
> >> >> > > > > (plus the CDVLocalFileSystem equivalent).
> >> >> > > > >
> >> >> > > > > Since Obj-C categories can't really "override" methods
> >>(behavior
> >> >> > > > > undefined), and I don't want to do some runtime swap
> >> >>implementation
> >> >> > > > voodoo,
> >> >> > > > > I would replace the line above with something like:
> >> >> > > > >
> >> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
> >> >> > > > > "assets-library:/%@",fullPath];
> >> >> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) {
> >>//
> >> >> some
> >> >> > > > > unique selector name perhaps
> >> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this code
> >> >>won't
> >> >> > > > > compile, pseudo-code for now. Will call my category method
> >> >>defined
> >> >> in
> >> >> > > my
> >> >> > > > > plugin for CDVAssetLibraryFileSystem
> >> >> > > > > }
> >> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
> >> >> > > > >
> >> >> > > > > Backwards compatible.
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com>
> >> >> wrote:
> >> >> > > > >
> >> >> > > > >> Local Web Server Checklist:
> >> >> > > > >> 1. We have random port usage
> >> >> > > > >> 2. We have the token/cookie check
> >> >> > > > >> 3. We have the localhost check
> >> >> > > > >> 4. The app is now installed under
> >>http://localhost:RANDOM_PORT
> >> >> /www/
> >> >> > > > >>
> >> >> > > > >> It'll be easy (relatively) to add support for:
> >> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
> >> >> > > > >> http://localhost:RANDOM_PORT/file-system/
> >> >> > > > >>
> >> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm
> >>thinking
> >> >>of
> >> >> > some
> >> >> > > > >> runtime 'magic' in the local web server where it detects the
> >> >>File
> >> >> > > > plugin,
> >> >> > > > >> and change the implementation of FileEntry.toURL() (or
> >>through
> >> >> > > injecting
> >> >> > > > >> JavaScript, probably easier).
> >> >> > > > >>
> >> >> > > > >>
> >> >> > > > >> 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
> >><sh...@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" <sh...@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
> >>
> >>
>
> B?KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB?
> ? [??X?昧?X?K K[XZ[ ? ]?][??X?昧?X?P 白? ??K?\ X? K????B???? Y ] [??[
> 栢[X[? ? K[XZ[ ? ]?Z [ 白? ??K?\ X? K????B
Re: [iOS 8] WKWebView moving forward
Posted by tommy-carlos williams <to...@devgeeks.org>.
Shazron,
I just noticed this in the README for the plugin:
"However, since requests are made over http, your app's activity may be visible to others on the name wi-fi network.”
Is this actually true? Why would traffic to localhost leave the device and be visible over the wifi?
--
tommy-carlos williams
On 20 November 2014 at 08:18:28, Homer, Tony (tony.homer@intel.com) wrote:
Ugh. Thanks for the additional information, Shazron.
I had previously proposed adding a hook (by which I meant a delegate
method) to CDVPluginResult (that would be called from -
(CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
message:(id)theMessage) so that LocalWebServer could (blindly) detect and
transform urls.
It seems like it would help with this case, but not be generally useful
for anything else…
Tony
On 11/19/14, 3:23 PM, "Shazron" <sh...@gmail.com> wrote:
>Ideally a general solution like you proposed should work, but I forgot to
>mention that in this case, since we are talking about WKWebView, we can't
>use NSURLProtocol since it is not supported in that framework [1][2]
>
>The only other general way I can see is to require explicit support in
>plugins, they may have to call something in the
>commandDelegate/viewController to transform a url, that can be set by
>another plugin, in this case LocalWebServer (my revised proposal was a
>'push' this is a 'pull').
>
>
>[1] https://issues.apache.org/jira/browse/CB-7049
>[2] http://www.openradar.me/18492325
>
>On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com>
>wrote:
>
>> If we are just talking about CB-8032, then I can see that this approach
>>is
>> cleaner for the file plugin.
>>
>> Regarding local web server plugin in general - what about other plugins
>> such as camera?
>> Doesn¹t there need to be a general solution that will provide
>> compatibility between local web server plugin and any plugin that
>>returns
>> a file protocol URL?
>>
>> Tony
>>
>> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
>>
>> >I commented on Ian's comment on CB-8032:
>> >
>>
>>https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p
>>a
>>
>>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
>>>en
>> >t-14216403
>> >
>> >My goal was to have a loose coupling of this functionality (CDVFile
>>need
>> >not know about LocalWebServer at all) -- and Ian's comment of this
>>change
>> >is that would impact all CDVFileSystem instances makes this not an
>>ideal
>> >solution, what if you have two Cordova WebView instances, etc.
>> >
>> >My revised proposal requires CDVFileSystem to have a delegate that can
>>be
>> >set. Any class can set it to override the nativeURL behaviour, and
>> >CDVFileSystem will call this method in the delegate if available. It
>> >achieves the same goal without the potentially undefined behaviour of
>>an
>> >Obj-C Category.
>> >
>> >The LocalWebServer gets the currently installed File plugin, enumerates
>> >all
>> >available filesystems, and sets this delegate on each, to its own
>> >implementation.
>> >
>> >Tony - I think this is approach is cleaner, and is more maintainable.
>> >
>> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <ic...@chromium.org>
>> >wrote:
>> >
>> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com>
>>wrote:
>> >>
>> >> > Shaz's solution has less impact and seems more elegant.
>> >> >
>> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>> >> >
>> >> > If no-one ( generically ) has provided the nativeFullPath method,
>>then
>> >> use
>> >> > it as is, otherwise call it.
>> >> > No need for any (direct) dependency between File + LocalServer.
>> >> >
>> >>
>> >> My first instinct, looking at the code, was that it was wrong,
>>exactly
>> >> because there *is* a dependency. You don't normally add code to a
>>base
>> >> class to change its behaviour when there is a category defined on it.
>> >> Normally that goes the other way: when you add a category to a base
>> >>class,
>> >> all of the code that's relevant to that category is *in the
>>category*,
>> >>and
>> >> the base class needs to know nothing at all about it, including its
>> >> existence.
>> >>
>> >> As I said in the PR, it may be that this really is the cleanest and
>>best
>> >> way to go forward with this; I just wanted to have this discussion
>>and
>> >> figure it out with the community before committing to any
>> >> hard-to-change-later technical debt. It does become an API surface,
>>and
>> >>we
>> >> will have to maintain whatever we adopt.
>> >>
>> >> Ian
>> >>
>> >>
>> >> >
>> >> > @purplecabbage
>> >> > risingj.com
>> >> >
>> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
>><agrieve@chromium.org
>> >
>> >> > wrote:
>> >> >
>> >> > > Having the localserver plugin add behaviour to file plugin feels
>> >>like
>> >> the
>> >> > > dependency is in the wrong direction to me.
>> >> > >
>> >> > > How about having CDVFile.m do something like:
>> >> > >
>> >> > > CDVPlugin* p = [commandDelegate
>>getCommandInstance:@"LocalServer"];
>> >> > > if (p != nil) {
>> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
>> >>declaration
>> >> to
>> >> > > make this not complain about unrecognized selector
>> >> > > }
>> >> > >
>> >> > > Would probably also need an "untransformURL" to go the other
>> >>direction
>> >> as
>> >> > > well.
>> >> > >
>> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com>
>> wrote:
>> >> > >
>> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
>> >> request
>> >> > > > included.
>> >> > > >
>> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com>
>> >>wrote:
>> >> > > >
>> >> > > > > Sorry I should have looked into the File API code first (no
>> >> > JavaScript
>> >> > > > > changes, that would not work).
>> >> > > > >
>> >> > > > > Essentially I need to "override" this line from my plugin:
>> >> > > > >
>> >> > > >
>> >> > > https://github.com/apache/cordova-plugin-file/blob/
>> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
>> >> > CDVAssetLibraryFilesystem.m#L74
>> >> > > > > (plus the CDVLocalFileSystem equivalent).
>> >> > > > >
>> >> > > > > Since Obj-C categories can't really "override" methods
>>(behavior
>> >> > > > > undefined), and I don't want to do some runtime swap
>> >>implementation
>> >> > > > voodoo,
>> >> > > > > I would replace the line above with something like:
>> >> > > > >
>> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
>> >> > > > > "assets-library:/%@",fullPath];
>> >> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>>//
>> >> some
>> >> > > > > unique selector name perhaps
>> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this code
>> >>won't
>> >> > > > > compile, pseudo-code for now. Will call my category method
>> >>defined
>> >> in
>> >> > > my
>> >> > > > > plugin for CDVAssetLibraryFileSystem
>> >> > > > > }
>> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
>> >> > > > >
>> >> > > > > Backwards compatible.
>> >> > > > >
>> >> > > > >
>> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com>
>> >> wrote:
>> >> > > > >
>> >> > > > >> Local Web Server Checklist:
>> >> > > > >> 1. We have random port usage
>> >> > > > >> 2. We have the token/cookie check
>> >> > > > >> 3. We have the localhost check
>> >> > > > >> 4. The app is now installed under
>>http://localhost:RANDOM_PORT
>> >> /www/
>> >> > > > >>
>> >> > > > >> It'll be easy (relatively) to add support for:
>> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
>> >> > > > >> http://localhost:RANDOM_PORT/file-system/
>> >> > > > >>
>> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm
>>thinking
>> >>of
>> >> > some
>> >> > > > >> runtime 'magic' in the local web server where it detects the
>> >>File
>> >> > > > plugin,
>> >> > > > >> and change the implementation of FileEntry.toURL() (or
>>through
>> >> > > injecting
>> >> > > > >> JavaScript, probably easier).
>> >> > > > >>
>> >> > > > >>
>> >> > > > >> 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
>><sh...@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" <sh...@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
>>
>>
B?KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB?? [??X?昧?X?KK[XZ[?]?][??X?昧?X?P白???K?\X?K????B????Y][??[栢[X[? ?K[XZ[?]?Z[ 白???K?\X?K????B
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
No idea yet Darryl
On Monday, June 8, 2015, Darryl Pogue <da...@dpogue.ca> wrote:
> Any news on IndexedDB bug fixes? Or working URL interceptors?
>
> On 8 June 2015 at 13:13, Shazron <shazron@gmail.com <javascript:;>> wrote:
> > Cordova developers rejoice, iOS 9 includes the API to load pages from
> > file:// urls https://twitter.com/wkwebview/status/608002548151119872
> >
> > On Mon, Feb 9, 2015 at 2:19 PM, Shazron <shazron@gmail.com
> <javascript:;>> wrote:
> >
> >> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> >> suppose for your dev machines and build servers...
> >>
> >>
> >> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> >> <tommy@devgeeks.org <javascript:;>> wrote:
> >> > Oh, FFS.
> >> >
> >> > I give up on Apple solving this, personally. Most apps don’t
> *actually*
> >> need it (they think they do, but they don’t). I am going to find another
> >> way to solve it for our apps… maybe I will actually have to write a
> native
> >> plugin for the crypto :(
> >> >
> >> > --
> >> > tommy-carlos williams
> >> >
> >> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com
> <javascript:;>) wrote:
> >> >
> >> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
> >> > the loadFileURL:readAccessURL: selector that we are all waiting for
> >> > :'(
> >> > https://twitter.com/wkwebview/status/564865657225756672
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@cordova.apache.org
> <javascript:;>
>
>
Re: [iOS 8] WKWebView moving forward
Posted by Darryl Pogue <da...@dpogue.ca>.
Any news on IndexedDB bug fixes? Or working URL interceptors?
On 8 June 2015 at 13:13, Shazron <sh...@gmail.com> wrote:
> Cordova developers rejoice, iOS 9 includes the API to load pages from
> file:// urls https://twitter.com/wkwebview/status/608002548151119872
>
> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
>
>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
>> suppose for your dev machines and build servers...
>>
>>
>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
>> <to...@devgeeks.org> wrote:
>> > Oh, FFS.
>> >
>> > I give up on Apple solving this, personally. Most apps don’t *actually*
>> need it (they think they do, but they don’t). I am going to find another
>> way to solve it for our apps… maybe I will actually have to write a native
>> plugin for the crypto :(
>> >
>> > --
>> > tommy-carlos williams
>> >
>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com) wrote:
>> >
>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
>> > the loadFileURL:readAccessURL: selector that we are all waiting for
>> > :'(
>> > https://twitter.com/wkwebview/status/564865657225756672
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [iOS 8] WKWebView moving forward
Posted by Kerri Shotts <ke...@gmail.com>.
Why am I hearing the Hallelujah chorus?
I’m dong my happy dance now! :-)
On June 8, 2015 at 3:14:14 PM, Shazron (shazron@gmail.com) wrote:
Cordova developers rejoice, iOS 9 includes the API to load pages from
file:// urls https://twitter.com/wkwebview/status/608002548151119872
On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> suppose for your dev machines and build servers...
>
>
> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> <to...@devgeeks.org> wrote:
> > Oh, FFS.
> >
> > I give up on Apple solving this, personally. Most apps don’t *actually*
> need it (they think they do, but they don’t). I am going to find another
> way to solve it for our apps… maybe I will actually have to write a native
> plugin for the crypto :(
> >
> > --
> > tommy-carlos williams
> >
> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com) wrote:
> >
> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
> > the loadFileURL:readAccessURL: selector that we are all waiting for
> > :'(
> > https://twitter.com/wkwebview/status/564865657225756672
>
Re: [iOS 8] WKWebView moving forward
Posted by Darryl Pogue <da...@dpogue.ca>.
IndexedDB news is looking a bit bleak:
https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26
On 9 June 2015 at 13:28, Shazron <sh...@gmail.com> wrote:
>
> Here's the juicy Safari iOS 9 bits, including new javascript and css
> features, including SFSafariViewController:
> https://developer.apple.com/library/prerelease/mac/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html
>
> On Tue, Jun 9, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
>
> > We could use it for InAppBrowser but we might lose some features that we
> > have possibly.
> >
> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
> > urls in Library and Documents, but not the app bundle.
> > https://twitter.com/wkwebview/status/608359163299819521
> >
> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com>
> > wrote:
> >
> >> Yay !
> >> There is also a new Safari View Controller, don't know if it's applicable
> >> to replace wkwebview but at least I think it can be use to build the next
> >> gen inappbrowser since its beats a makeup in iOS anyway.
> >>
> >> The session is in 30 minutes so I'm planning attending.
> >> On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> >>
> >> > There is a WWDC session: "Safari Extensibility: Content Blocking and
> >> Shared
> >> > Links". So I'm hopeful for whitelisting
> >> >
> >> > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
> >> >
> >> > > Moar news https://twitter.com/wkwebview/status/608005652720451584
> >> > >
> >> > >
> >> > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> >> > >
> >> > >> Cordova developers rejoice, iOS 9 includes the API to load pages from
> >> > >> file:// urls https://twitter.com/wkwebview/status/608002548151119872
> >> > >>
> >> > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
> >> > >>
> >> > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> >> > >>> suppose for your dev machines and build servers...
> >> > >>>
> >> > >>>
> >> > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> >> > >>> <to...@devgeeks.org> wrote:
> >> > >>> > Oh, FFS.
> >> > >>> >
> >> > >>> > I give up on Apple solving this, personally. Most apps don’t
> >> > >>> *actually* need it (they think they do, but they don’t). I am going
> >> to
> >> > find
> >> > >>> another way to solve it for our apps… maybe I will actually have to
> >> > write a
> >> > >>> native plugin for the crypto :(
> >> > >>> >
> >> > >>> > --
> >> > >>> > tommy-carlos williams
> >> > >>> >
> >> > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com)
> >> wrote:
> >> > >>> >
> >> > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
> >> contain
> >> > >>> > the loadFileURL:readAccessURL: selector that we are all waiting
> >> for
> >> > >>> > :'(
> >> > >>> > https://twitter.com/wkwebview/status/564865657225756672
> >> > >>>
> >> > >>
> >> > >>
> >> >
> >>
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Here's the juicy Safari iOS 9 bits, including new javascript and css
features, including SFSafariViewController:
https://developer.apple.com/library/prerelease/mac/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html
On Tue, Jun 9, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
> We could use it for InAppBrowser but we might lose some features that we
> have possibly.
>
> Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
> urls in Library and Documents, but not the app bundle.
> https://twitter.com/wkwebview/status/608359163299819521
>
> On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com>
> wrote:
>
>> Yay !
>> There is also a new Safari View Controller, don't know if it's applicable
>> to replace wkwebview but at least I think it can be use to build the next
>> gen inappbrowser since its beats a makeup in iOS anyway.
>>
>> The session is in 30 minutes so I'm planning attending.
>> On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
>>
>> > There is a WWDC session: "Safari Extensibility: Content Blocking and
>> Shared
>> > Links". So I'm hopeful for whitelisting
>> >
>> > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
>> >
>> > > Moar news https://twitter.com/wkwebview/status/608005652720451584
>> > >
>> > >
>> > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
>> > >
>> > >> Cordova developers rejoice, iOS 9 includes the API to load pages from
>> > >> file:// urls https://twitter.com/wkwebview/status/608002548151119872
>> > >>
>> > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
>> > >>
>> > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
>> > >>> suppose for your dev machines and build servers...
>> > >>>
>> > >>>
>> > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
>> > >>> <to...@devgeeks.org> wrote:
>> > >>> > Oh, FFS.
>> > >>> >
>> > >>> > I give up on Apple solving this, personally. Most apps don’t
>> > >>> *actually* need it (they think they do, but they don’t). I am going
>> to
>> > find
>> > >>> another way to solve it for our apps… maybe I will actually have to
>> > write a
>> > >>> native plugin for the crypto :(
>> > >>> >
>> > >>> > --
>> > >>> > tommy-carlos williams
>> > >>> >
>> > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com)
>> wrote:
>> > >>> >
>> > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
>> contain
>> > >>> > the loadFileURL:readAccessURL: selector that we are all waiting
>> for
>> > >>> > :'(
>> > >>> > https://twitter.com/wkwebview/status/564865657225756672
>> > >>>
>> > >>
>> > >>
>> >
>>
>
>
Re: [iOS 8] WKWebView moving forward
Posted by tommy-carlos williams <to...@devgeeks.org>.
I hadn’t considered the space issue. Mind you, my apps are like 1.7MB. Not exactly space hogs. At least the camera and downloads issues would be fixed :(
--
tommy-carlos williams
On 10 June 2015 at 07:04:00, Shazron (shazron@gmail.com) wrote:
+1 to what Kerri said.
If we did it, it would be in Library/Caches since that is not backed up by
iTunes:
https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1
On Tue, Jun 9, 2015 at 1:58 PM, Kerri Shotts <ke...@gmail.com> wrote:
> Speaking as a user who has an iPhone that’s always running near the
> storage limit: I’d hate to see files be duplicate out of the bundle into
> another location… my phone might cry.
>
> I think we went over that when WKWebview was first released. Copying files
> was discussed, but it adds an awful lot of complexity to startup, wastes
> space, etc. Looks like the local web server might be the best option, still.
>
> But I guess this gives the option of using web content that the app itself
> downloads to /Documents or /Library, so that could be nice. Unfortunate
> that they hamstrung it regarding bundles tho. Here’s hoping they’ll change
> it, but given the track record in iOS 8, I’m not holding my breath.
>
>
>
>
> On June 9, 2015 at 3:50:09 PM, Ross Gerbasi (rgerbasi@gmail.com) wrote:
>
> Would it be a horrible idea to copy files into one of those folders?
>
> On Tue, Jun 9, 2015 at 3:22 PM, Shazron <sh...@gmail.com> wrote:
>
> > We could use it for InAppBrowser but we might lose some features that we
> > have possibly.
> >
> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
> urls
> > in Library and Documents, but not the app bundle.
> > https://twitter.com/wkwebview/status/608359163299819521
> >
> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com>
> > wrote:
> >
> > > Yay !
> > > There is also a new Safari View Controller, don't know if it's
> applicable
> > > to replace wkwebview but at least I think it can be use to build the
> next
> > > gen inappbrowser since its beats a makeup in iOS anyway.
> > >
> > > The session is in 30 minutes so I'm planning attending.
> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> > >
> > > > There is a WWDC session: "Safari Extensibility: Content Blocking and
> > > Shared
> > > > Links". So I'm hopeful for whitelisting
> > > >
> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
> > > >
> > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584
> > > > >
> > > > >
> > > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> > > > >
> > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages
> > from
> > > > >> file:// urls
> > https://twitter.com/wkwebview/status/608002548151119872
> > > > >>
> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com>
> wrote:
> > > > >>
> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> > > > >>> suppose for your dev machines and build servers...
> > > > >>>
> > > > >>>
> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> > > > >>> <to...@devgeeks.org> wrote:
> > > > >>> > Oh, FFS.
> > > > >>> >
> > > > >>> > I give up on Apple solving this, personally. Most apps don’t
> > > > >>> *actually* need it (they think they do, but they don’t). I am
> going
> > > to
> > > > find
> > > > >>> another way to solve it for our apps… maybe I will actually have
> to
> > > > write a
> > > > >>> native plugin for the crypto :(
> > > > >>> >
> > > > >>> > --
> > > > >>> > tommy-carlos williams
> > > > >>> >
> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com)
> > > wrote:
> > > > >>> >
> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
> > > contain
> > > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting
> > for
> > > > >>> > :'(
> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
+1 to what Kerri said.
If we did it, it would be in Library/Caches since that is not backed up by
iTunes:
https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1
On Tue, Jun 9, 2015 at 1:58 PM, Kerri Shotts <ke...@gmail.com> wrote:
> Speaking as a user who has an iPhone that’s always running near the
> storage limit: I’d hate to see files be duplicate out of the bundle into
> another location… my phone might cry.
>
> I think we went over that when WKWebview was first released. Copying files
> was discussed, but it adds an awful lot of complexity to startup, wastes
> space, etc. Looks like the local web server might be the best option, still.
>
> But I guess this gives the option of using web content that the app itself
> downloads to /Documents or /Library, so that could be nice. Unfortunate
> that they hamstrung it regarding bundles tho. Here’s hoping they’ll change
> it, but given the track record in iOS 8, I’m not holding my breath.
>
>
>
>
> On June 9, 2015 at 3:50:09 PM, Ross Gerbasi (rgerbasi@gmail.com) wrote:
>
> Would it be a horrible idea to copy files into one of those folders?
>
> On Tue, Jun 9, 2015 at 3:22 PM, Shazron <sh...@gmail.com> wrote:
>
> > We could use it for InAppBrowser but we might lose some features that we
> > have possibly.
> >
> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
> urls
> > in Library and Documents, but not the app bundle.
> > https://twitter.com/wkwebview/status/608359163299819521
> >
> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com>
> > wrote:
> >
> > > Yay !
> > > There is also a new Safari View Controller, don't know if it's
> applicable
> > > to replace wkwebview but at least I think it can be use to build the
> next
> > > gen inappbrowser since its beats a makeup in iOS anyway.
> > >
> > > The session is in 30 minutes so I'm planning attending.
> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> > >
> > > > There is a WWDC session: "Safari Extensibility: Content Blocking and
> > > Shared
> > > > Links". So I'm hopeful for whitelisting
> > > >
> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
> > > >
> > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584
> > > > >
> > > > >
> > > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> > > > >
> > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages
> > from
> > > > >> file:// urls
> > https://twitter.com/wkwebview/status/608002548151119872
> > > > >>
> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com>
> wrote:
> > > > >>
> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> > > > >>> suppose for your dev machines and build servers...
> > > > >>>
> > > > >>>
> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> > > > >>> <to...@devgeeks.org> wrote:
> > > > >>> > Oh, FFS.
> > > > >>> >
> > > > >>> > I give up on Apple solving this, personally. Most apps don’t
> > > > >>> *actually* need it (they think they do, but they don’t). I am
> going
> > > to
> > > > find
> > > > >>> another way to solve it for our apps… maybe I will actually have
> to
> > > > write a
> > > > >>> native plugin for the crypto :(
> > > > >>> >
> > > > >>> > --
> > > > >>> > tommy-carlos williams
> > > > >>> >
> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com)
> > > wrote:
> > > > >>> >
> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
> > > contain
> > > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting
> > for
> > > > >>> > :'(
> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Kerri Shotts <ke...@gmail.com>.
Speaking as a user who has an iPhone that’s always running near the storage limit: I’d hate to see files be duplicate out of the bundle into another location… my phone might cry.
I think we went over that when WKWebview was first released. Copying files was discussed, but it adds an awful lot of complexity to startup, wastes space, etc. Looks like the local web server might be the best option, still.
But I guess this gives the option of using web content that the app itself downloads to /Documents or /Library, so that could be nice. Unfortunate that they hamstrung it regarding bundles tho. Here’s hoping they’ll change it, but given the track record in iOS 8, I’m not holding my breath.
On June 9, 2015 at 3:50:09 PM, Ross Gerbasi (rgerbasi@gmail.com) wrote:
Would it be a horrible idea to copy files into one of those folders?
On Tue, Jun 9, 2015 at 3:22 PM, Shazron <sh...@gmail.com> wrote:
> We could use it for InAppBrowser but we might lose some features that we
> have possibly.
>
> Anyways, one piece of bad news for WKWebView iOS 9 - you can load file urls
> in Library and Documents, but not the app bundle.
> https://twitter.com/wkwebview/status/608359163299819521
>
> On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com>
> wrote:
>
> > Yay !
> > There is also a new Safari View Controller, don't know if it's applicable
> > to replace wkwebview but at least I think it can be use to build the next
> > gen inappbrowser since its beats a makeup in iOS anyway.
> >
> > The session is in 30 minutes so I'm planning attending.
> > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> >
> > > There is a WWDC session: "Safari Extensibility: Content Blocking and
> > Shared
> > > Links". So I'm hopeful for whitelisting
> > >
> > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > > > Moar news https://twitter.com/wkwebview/status/608005652720451584
> > > >
> > > >
> > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> > > >
> > > >> Cordova developers rejoice, iOS 9 includes the API to load pages
> from
> > > >> file:// urls
> https://twitter.com/wkwebview/status/608002548151119872
> > > >>
> > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
> > > >>
> > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> > > >>> suppose for your dev machines and build servers...
> > > >>>
> > > >>>
> > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> > > >>> <to...@devgeeks.org> wrote:
> > > >>> > Oh, FFS.
> > > >>> >
> > > >>> > I give up on Apple solving this, personally. Most apps don’t
> > > >>> *actually* need it (they think they do, but they don’t). I am going
> > to
> > > find
> > > >>> another way to solve it for our apps… maybe I will actually have to
> > > write a
> > > >>> native plugin for the crypto :(
> > > >>> >
> > > >>> > --
> > > >>> > tommy-carlos williams
> > > >>> >
> > > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com)
> > wrote:
> > > >>> >
> > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
> > contain
> > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting
> for
> > > >>> > :'(
> > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> > > >>>
> > > >>
> > > >>
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Ross Gerbasi <rg...@gmail.com>.
Would it be a horrible idea to copy files into one of those folders?
On Tue, Jun 9, 2015 at 3:22 PM, Shazron <sh...@gmail.com> wrote:
> We could use it for InAppBrowser but we might lose some features that we
> have possibly.
>
> Anyways, one piece of bad news for WKWebView iOS 9 - you can load file urls
> in Library and Documents, but not the app bundle.
> https://twitter.com/wkwebview/status/608359163299819521
>
> On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com>
> wrote:
>
> > Yay !
> > There is also a new Safari View Controller, don't know if it's applicable
> > to replace wkwebview but at least I think it can be use to build the next
> > gen inappbrowser since its beats a makeup in iOS anyway.
> >
> > The session is in 30 minutes so I'm planning attending.
> > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> >
> > > There is a WWDC session: "Safari Extensibility: Content Blocking and
> > Shared
> > > Links". So I'm hopeful for whitelisting
> > >
> > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > > > Moar news https://twitter.com/wkwebview/status/608005652720451584
> > > >
> > > >
> > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> > > >
> > > >> Cordova developers rejoice, iOS 9 includes the API to load pages
> from
> > > >> file:// urls
> https://twitter.com/wkwebview/status/608002548151119872
> > > >>
> > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
> > > >>
> > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> > > >>> suppose for your dev machines and build servers...
> > > >>>
> > > >>>
> > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> > > >>> <to...@devgeeks.org> wrote:
> > > >>> > Oh, FFS.
> > > >>> >
> > > >>> > I give up on Apple solving this, personally. Most apps don’t
> > > >>> *actually* need it (they think they do, but they don’t). I am going
> > to
> > > find
> > > >>> another way to solve it for our apps… maybe I will actually have to
> > > write a
> > > >>> native plugin for the crypto :(
> > > >>> >
> > > >>> > --
> > > >>> > tommy-carlos williams
> > > >>> >
> > > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com)
> > wrote:
> > > >>> >
> > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
> > contain
> > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting
> for
> > > >>> > :'(
> > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> > > >>>
> > > >>
> > > >>
> > >
> >
>
RE: [iOS 8] WKWebView moving forward
Posted by Chuck Lantz <cl...@microsoft.com>.
Hmmm. Symlinks will break if the code ever touches Windows but they could be safely created as a part of a before_compile hook since that would only ever run on OSX practically speaking. (after_prepare would still fire if you add iOS on Windows - which is something we talked about being a potential issue if platforms are referenced in package.json.)
-Chuck
-----Original Message-----
From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of Andrew Grieve
Sent: Thursday, June 11, 2015 11:27 AM
To: dev
Subject: Re: [iOS 8] WKWebView moving forward
Could maybe try creating symlinks / hardlinks to save on space / creation time?
On Wed, Jun 10, 2015 at 12:00 PM, Shazron <sh...@gmail.com> wrote:
> Safari View Controller video:
> https://developer.apple.com/videos/wwdc/2015/?id=504
>
> What's New in Web Development in WebKit and Safari video:
> https://developer.apple.com/videos/wwdc/2015/?id=501
>
>
> On Tue, Jun 9, 2015 at 3:59 PM, Shazron <sh...@gmail.com> wrote:
>
> > I definitely will watch.
> > Just read about ODR
> >
> https://developer.apple.com/library/prerelease/ios/documentation/FileM
> anagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.htm
> l#//apple_ref/doc/uid/TP40015083-CH2-SW1
> >
> > So we could still use the copy method (fast, small app bundle) and
> > have a solution in Cordova for ODR for app bundles that are huge.
> > For example,
> in
> > the CLI prepare step.
> >
> > Of course this won't be a universal solution and is more complicated.
> >
> > On Tuesday, June 9, 2015, Carlos Santana <cs...@gmail.com> wrote:
> >
> >> What do we loose, I just attended the session.
> >> I think for most uses is a win at least in the security aspect
> >> Watch the session when the video is available and we can discuss later.
> >>
> >> On Tue, Jun 9, 2015 at 1:23 PM Shazron <sh...@gmail.com> wrote:
> >>
> >> > We could use it for InAppBrowser but we might lose some features
> >> > that
> we
> >> > have possibly.
> >> >
> >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load
> >> > file
> >> urls
> >> > in Library and Documents, but not the app bundle.
> >> > https://twitter.com/wkwebview/status/608359163299819521
> >> >
> >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana
> >> > <cs...@gmail.com>
> >> > wrote:
> >> >
> >> > > Yay !
> >> > > There is also a new Safari View Controller, don't know if it's
> >> applicable
> >> > > to replace wkwebview but at least I think it can be use to
> >> > > build the
> >> next
> >> > > gen inappbrowser since its beats a makeup in iOS anyway.
> >> > >
> >> > > The session is in 30 minutes so I'm planning attending.
> >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> >> > >
> >> > > > There is a WWDC session: "Safari Extensibility: Content
> >> > > > Blocking
> and
> >> > > Shared
> >> > > > Links". So I'm hopeful for whitelisting
> >> > > >
> >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com>
> wrote:
> >> > > >
> >> > > > > Moar news
> https://twitter.com/wkwebview/status/608005652720451584
> >> > > > >
> >> > > > >
> >> > > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> >> > > > >
> >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load
> pages
> >> > from
> >> > > > >> file:// urls
> >> > https://twitter.com/wkwebview/status/608002548151119872
> >> > > > >>
> >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron
> >> > > > >> <sh...@gmail.com>
> >> wrote:
> >> > > > >>
> >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to
> upgrade
> >> I
> >> > > > >>> suppose for your dev machines and build servers...
> >> > > > >>>
> >> > > > >>>
> >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> >> > > > >>> <to...@devgeeks.org> wrote:
> >> > > > >>> > Oh, FFS.
> >> > > > >>> >
> >> > > > >>> > I give up on Apple solving this, personally. Most apps
> >> > > > >>> > don’t
> >> > > > >>> *actually* need it (they think they do, but they don’t).
> >> > > > >>> I am
> >> going
> >> > > to
> >> > > > find
> >> > > > >>> another way to solve it for our apps… maybe I will
> >> > > > >>> actually
> >> have to
> >> > > > write a
> >> > > > >>> native plugin for the crypto :(
> >> > > > >>> >
> >> > > > >>> > --
> >> > > > >>> > tommy-carlos williams
> >> > > > >>> >
> >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron
> >> > > > >>> > (shazron@gmail.com
> )
> >> > > wrote:
> >> > > > >>> >
> >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does
> >> > > > >>> > *not*
> >> > > contain
> >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all
> >> waiting
> >> > for
> >> > > > >>> > :'(
> >> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> >> > > > >>>
> >> > > > >>
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Carlos Santana <cs...@gmail.com>.
I don't see moving the files to document out from bundle to documents on
first lunch as terrible thing. It can be implemented in the mean while.
In our downstream district of cordova this is how we handle dynamic app
update from server since bundle is read only.
But agree best solution is for wkwebview have proper fix.
On Thu, Jun 11, 2015 at 12:09 PM Kerri Shotts <ke...@gmail.com> wrote:
> Yeah, I was just about to say that I was pretty sure that sym/hard links
> was going to error.
>
> But that tweet looks promising! I hope that means the fix makes it in time
> for Beta 2 so we can play with it. :-)
>
>
>
>
> On June 11, 2015 at 1:55:58 PM, Shazron (shazron@gmail.com) wrote:
>
> I've already tried both sym and hard links. They result in errors, which is
> to be expected (if not there's some 'splaining to do) :P
>
> GOOD news though today! They are fixing the app bundle loadFileURL bug:
> https://twitter.com/grorgwork/status/609052546179530752
>
> Apparently you can also UI test in WKWebView:
> https://twitter.com/joemasilotti/status/609000047930429440
>
> On Thu, Jun 11, 2015 at 11:26 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Could maybe try creating symlinks / hardlinks to save on space / creation
> > time?
> >
> > On Wed, Jun 10, 2015 at 12:00 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > Safari View Controller video:
> > > https://developer.apple.com/videos/wwdc/2015/?id=504
> > >
> > > What's New in Web Development in WebKit and Safari video:
> > > https://developer.apple.com/videos/wwdc/2015/?id=501
> > >
> > >
> > > On Tue, Jun 9, 2015 at 3:59 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > > > I definitely will watch.
> > > > Just read about ODR
> > > >
> > >
> >
> https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1
> > > >
> > > > So we could still use the copy method (fast, small app bundle) and
> > have a
> > > > solution in Cordova for ODR for app bundles that are huge. For
> example,
> > > in
> > > > the CLI prepare step.
> > > >
> > > > Of course this won't be a universal solution and is more complicated.
> > > >
> > > > On Tuesday, June 9, 2015, Carlos Santana <cs...@gmail.com>
> wrote:
> > > >
> > > >> What do we loose, I just attended the session.
> > > >> I think for most uses is a win at least in the security aspect
> > > >> Watch the session when the video is available and we can discuss
> > later.
> > > >>
> > > >> On Tue, Jun 9, 2015 at 1:23 PM Shazron <sh...@gmail.com> wrote:
> > > >>
> > > >> > We could use it for InAppBrowser but we might lose some features
> > that
> > > we
> > > >> > have possibly.
> > > >> >
> > > >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load
> > file
> > > >> urls
> > > >> > in Library and Documents, but not the app bundle.
> > > >> > https://twitter.com/wkwebview/status/608359163299819521
> > > >> >
> > > >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <
> > csantana23@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > Yay !
> > > >> > > There is also a new Safari View Controller, don't know if it's
> > > >> applicable
> > > >> > > to replace wkwebview but at least I think it can be use to build
> > the
> > > >> next
> > > >> > > gen inappbrowser since its beats a makeup in iOS anyway.
> > > >> > >
> > > >> > > The session is in 30 minutes so I'm planning attending.
> > > >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com>
> wrote:
> > > >> > >
> > > >> > > > There is a WWDC session: "Safari Extensibility: Content
> Blocking
> > > and
> > > >> > > Shared
> > > >> > > > Links". So I'm hopeful for whitelisting
> > > >> > > >
> > > >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com>
> > > wrote:
> > > >> > > >
> > > >> > > > > Moar news
> > > https://twitter.com/wkwebview/status/608005652720451584
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> > > >> > > > >
> > > >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load
> > > pages
> > > >> > from
> > > >> > > > >> file:// urls
> > > >> > https://twitter.com/wkwebview/status/608002548151119872
> > > >> > > > >>
> > > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <shazron@gmail.com
> >
> > > >> wrote:
> > > >> > > > >>
> > > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to
> > > upgrade
> > > >> I
> > > >> > > > >>> suppose for your dev machines and build servers...
> > > >> > > > >>>
> > > >> > > > >>>
> > > >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> > > >> > > > >>> <to...@devgeeks.org> wrote:
> > > >> > > > >>> > Oh, FFS.
> > > >> > > > >>> >
> > > >> > > > >>> > I give up on Apple solving this, personally. Most apps
> > don’t
> > > >> > > > >>> *actually* need it (they think they do, but they don’t). I
> > am
> > > >> going
> > > >> > > to
> > > >> > > > find
> > > >> > > > >>> another way to solve it for our apps… maybe I will
> actually
> > > >> have to
> > > >> > > > write a
> > > >> > > > >>> native plugin for the crypto :(
> > > >> > > > >>> >
> > > >> > > > >>> > --
> > > >> > > > >>> > tommy-carlos williams
> > > >> > > > >>> >
> > > >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (
> > shazron@gmail.com
> > > )
> > > >> > > wrote:
> > > >> > > > >>> >
> > > >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does
> > *not*
> > > >> > > contain
> > > >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all
> > > >> waiting
> > > >> > for
> > > >> > > > >>> > :'(
> > > >> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> > > >> > > > >>>
> > > >> > > > >>
> > > >> > > > >>
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Kerri Shotts <ke...@gmail.com>.
Yeah, I was just about to say that I was pretty sure that sym/hard links was going to error.
But that tweet looks promising! I hope that means the fix makes it in time for Beta 2 so we can play with it. :-)
On June 11, 2015 at 1:55:58 PM, Shazron (shazron@gmail.com) wrote:
I've already tried both sym and hard links. They result in errors, which is
to be expected (if not there's some 'splaining to do) :P
GOOD news though today! They are fixing the app bundle loadFileURL bug:
https://twitter.com/grorgwork/status/609052546179530752
Apparently you can also UI test in WKWebView:
https://twitter.com/joemasilotti/status/609000047930429440
On Thu, Jun 11, 2015 at 11:26 AM, Andrew Grieve <ag...@chromium.org>
wrote:
> Could maybe try creating symlinks / hardlinks to save on space / creation
> time?
>
> On Wed, Jun 10, 2015 at 12:00 PM, Shazron <sh...@gmail.com> wrote:
>
> > Safari View Controller video:
> > https://developer.apple.com/videos/wwdc/2015/?id=504
> >
> > What's New in Web Development in WebKit and Safari video:
> > https://developer.apple.com/videos/wwdc/2015/?id=501
> >
> >
> > On Tue, Jun 9, 2015 at 3:59 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > I definitely will watch.
> > > Just read about ODR
> > >
> >
> https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1
> > >
> > > So we could still use the copy method (fast, small app bundle) and
> have a
> > > solution in Cordova for ODR for app bundles that are huge. For example,
> > in
> > > the CLI prepare step.
> > >
> > > Of course this won't be a universal solution and is more complicated.
> > >
> > > On Tuesday, June 9, 2015, Carlos Santana <cs...@gmail.com> wrote:
> > >
> > >> What do we loose, I just attended the session.
> > >> I think for most uses is a win at least in the security aspect
> > >> Watch the session when the video is available and we can discuss
> later.
> > >>
> > >> On Tue, Jun 9, 2015 at 1:23 PM Shazron <sh...@gmail.com> wrote:
> > >>
> > >> > We could use it for InAppBrowser but we might lose some features
> that
> > we
> > >> > have possibly.
> > >> >
> > >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load
> file
> > >> urls
> > >> > in Library and Documents, but not the app bundle.
> > >> > https://twitter.com/wkwebview/status/608359163299819521
> > >> >
> > >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <
> csantana23@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Yay !
> > >> > > There is also a new Safari View Controller, don't know if it's
> > >> applicable
> > >> > > to replace wkwebview but at least I think it can be use to build
> the
> > >> next
> > >> > > gen inappbrowser since its beats a makeup in iOS anyway.
> > >> > >
> > >> > > The session is in 30 minutes so I'm planning attending.
> > >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> > >> > >
> > >> > > > There is a WWDC session: "Safari Extensibility: Content Blocking
> > and
> > >> > > Shared
> > >> > > > Links". So I'm hopeful for whitelisting
> > >> > > >
> > >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com>
> > wrote:
> > >> > > >
> > >> > > > > Moar news
> > https://twitter.com/wkwebview/status/608005652720451584
> > >> > > > >
> > >> > > > >
> > >> > > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> > >> > > > >
> > >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load
> > pages
> > >> > from
> > >> > > > >> file:// urls
> > >> > https://twitter.com/wkwebview/status/608002548151119872
> > >> > > > >>
> > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com>
> > >> wrote:
> > >> > > > >>
> > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to
> > upgrade
> > >> I
> > >> > > > >>> suppose for your dev machines and build servers...
> > >> > > > >>>
> > >> > > > >>>
> > >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> > >> > > > >>> <to...@devgeeks.org> wrote:
> > >> > > > >>> > Oh, FFS.
> > >> > > > >>> >
> > >> > > > >>> > I give up on Apple solving this, personally. Most apps
> don’t
> > >> > > > >>> *actually* need it (they think they do, but they don’t). I
> am
> > >> going
> > >> > > to
> > >> > > > find
> > >> > > > >>> another way to solve it for our apps… maybe I will actually
> > >> have to
> > >> > > > write a
> > >> > > > >>> native plugin for the crypto :(
> > >> > > > >>> >
> > >> > > > >>> > --
> > >> > > > >>> > tommy-carlos williams
> > >> > > > >>> >
> > >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (
> shazron@gmail.com
> > )
> > >> > > wrote:
> > >> > > > >>> >
> > >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does
> *not*
> > >> > > contain
> > >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all
> > >> waiting
> > >> > for
> > >> > > > >>> > :'(
> > >> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> > >> > > > >>>
> > >> > > > >>
> > >> > > > >>
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
I've already tried both sym and hard links. They result in errors, which is
to be expected (if not there's some 'splaining to do) :P
GOOD news though today! They are fixing the app bundle loadFileURL bug:
https://twitter.com/grorgwork/status/609052546179530752
Apparently you can also UI test in WKWebView:
https://twitter.com/joemasilotti/status/609000047930429440
On Thu, Jun 11, 2015 at 11:26 AM, Andrew Grieve <ag...@chromium.org>
wrote:
> Could maybe try creating symlinks / hardlinks to save on space / creation
> time?
>
> On Wed, Jun 10, 2015 at 12:00 PM, Shazron <sh...@gmail.com> wrote:
>
> > Safari View Controller video:
> > https://developer.apple.com/videos/wwdc/2015/?id=504
> >
> > What's New in Web Development in WebKit and Safari video:
> > https://developer.apple.com/videos/wwdc/2015/?id=501
> >
> >
> > On Tue, Jun 9, 2015 at 3:59 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > I definitely will watch.
> > > Just read about ODR
> > >
> >
> https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1
> > >
> > > So we could still use the copy method (fast, small app bundle) and
> have a
> > > solution in Cordova for ODR for app bundles that are huge. For example,
> > in
> > > the CLI prepare step.
> > >
> > > Of course this won't be a universal solution and is more complicated.
> > >
> > > On Tuesday, June 9, 2015, Carlos Santana <cs...@gmail.com> wrote:
> > >
> > >> What do we loose, I just attended the session.
> > >> I think for most uses is a win at least in the security aspect
> > >> Watch the session when the video is available and we can discuss
> later.
> > >>
> > >> On Tue, Jun 9, 2015 at 1:23 PM Shazron <sh...@gmail.com> wrote:
> > >>
> > >> > We could use it for InAppBrowser but we might lose some features
> that
> > we
> > >> > have possibly.
> > >> >
> > >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load
> file
> > >> urls
> > >> > in Library and Documents, but not the app bundle.
> > >> > https://twitter.com/wkwebview/status/608359163299819521
> > >> >
> > >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <
> csantana23@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Yay !
> > >> > > There is also a new Safari View Controller, don't know if it's
> > >> applicable
> > >> > > to replace wkwebview but at least I think it can be use to build
> the
> > >> next
> > >> > > gen inappbrowser since its beats a makeup in iOS anyway.
> > >> > >
> > >> > > The session is in 30 minutes so I'm planning attending.
> > >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> > >> > >
> > >> > > > There is a WWDC session: "Safari Extensibility: Content Blocking
> > and
> > >> > > Shared
> > >> > > > Links". So I'm hopeful for whitelisting
> > >> > > >
> > >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com>
> > wrote:
> > >> > > >
> > >> > > > > Moar news
> > https://twitter.com/wkwebview/status/608005652720451584
> > >> > > > >
> > >> > > > >
> > >> > > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> > >> > > > >
> > >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load
> > pages
> > >> > from
> > >> > > > >> file:// urls
> > >> > https://twitter.com/wkwebview/status/608002548151119872
> > >> > > > >>
> > >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com>
> > >> wrote:
> > >> > > > >>
> > >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to
> > upgrade
> > >> I
> > >> > > > >>> suppose for your dev machines and build servers...
> > >> > > > >>>
> > >> > > > >>>
> > >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> > >> > > > >>> <to...@devgeeks.org> wrote:
> > >> > > > >>> > Oh, FFS.
> > >> > > > >>> >
> > >> > > > >>> > I give up on Apple solving this, personally. Most apps
> don’t
> > >> > > > >>> *actually* need it (they think they do, but they don’t). I
> am
> > >> going
> > >> > > to
> > >> > > > find
> > >> > > > >>> another way to solve it for our apps… maybe I will actually
> > >> have to
> > >> > > > write a
> > >> > > > >>> native plugin for the crypto :(
> > >> > > > >>> >
> > >> > > > >>> > --
> > >> > > > >>> > tommy-carlos williams
> > >> > > > >>> >
> > >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (
> shazron@gmail.com
> > )
> > >> > > wrote:
> > >> > > > >>> >
> > >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does
> *not*
> > >> > > contain
> > >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all
> > >> waiting
> > >> > for
> > >> > > > >>> > :'(
> > >> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> > >> > > > >>>
> > >> > > > >>
> > >> > > > >>
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Andrew Grieve <ag...@chromium.org>.
Could maybe try creating symlinks / hardlinks to save on space / creation
time?
On Wed, Jun 10, 2015 at 12:00 PM, Shazron <sh...@gmail.com> wrote:
> Safari View Controller video:
> https://developer.apple.com/videos/wwdc/2015/?id=504
>
> What's New in Web Development in WebKit and Safari video:
> https://developer.apple.com/videos/wwdc/2015/?id=501
>
>
> On Tue, Jun 9, 2015 at 3:59 PM, Shazron <sh...@gmail.com> wrote:
>
> > I definitely will watch.
> > Just read about ODR
> >
> https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1
> >
> > So we could still use the copy method (fast, small app bundle) and have a
> > solution in Cordova for ODR for app bundles that are huge. For example,
> in
> > the CLI prepare step.
> >
> > Of course this won't be a universal solution and is more complicated.
> >
> > On Tuesday, June 9, 2015, Carlos Santana <cs...@gmail.com> wrote:
> >
> >> What do we loose, I just attended the session.
> >> I think for most uses is a win at least in the security aspect
> >> Watch the session when the video is available and we can discuss later.
> >>
> >> On Tue, Jun 9, 2015 at 1:23 PM Shazron <sh...@gmail.com> wrote:
> >>
> >> > We could use it for InAppBrowser but we might lose some features that
> we
> >> > have possibly.
> >> >
> >> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
> >> urls
> >> > in Library and Documents, but not the app bundle.
> >> > https://twitter.com/wkwebview/status/608359163299819521
> >> >
> >> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com>
> >> > wrote:
> >> >
> >> > > Yay !
> >> > > There is also a new Safari View Controller, don't know if it's
> >> applicable
> >> > > to replace wkwebview but at least I think it can be use to build the
> >> next
> >> > > gen inappbrowser since its beats a makeup in iOS anyway.
> >> > >
> >> > > The session is in 30 minutes so I'm planning attending.
> >> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> >> > >
> >> > > > There is a WWDC session: "Safari Extensibility: Content Blocking
> and
> >> > > Shared
> >> > > > Links". So I'm hopeful for whitelisting
> >> > > >
> >> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com>
> wrote:
> >> > > >
> >> > > > > Moar news
> https://twitter.com/wkwebview/status/608005652720451584
> >> > > > >
> >> > > > >
> >> > > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> >> > > > >
> >> > > > >> Cordova developers rejoice, iOS 9 includes the API to load
> pages
> >> > from
> >> > > > >> file:// urls
> >> > https://twitter.com/wkwebview/status/608002548151119872
> >> > > > >>
> >> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com>
> >> wrote:
> >> > > > >>
> >> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to
> upgrade
> >> I
> >> > > > >>> suppose for your dev machines and build servers...
> >> > > > >>>
> >> > > > >>>
> >> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> >> > > > >>> <to...@devgeeks.org> wrote:
> >> > > > >>> > Oh, FFS.
> >> > > > >>> >
> >> > > > >>> > I give up on Apple solving this, personally. Most apps don’t
> >> > > > >>> *actually* need it (they think they do, but they don’t). I am
> >> going
> >> > > to
> >> > > > find
> >> > > > >>> another way to solve it for our apps… maybe I will actually
> >> have to
> >> > > > write a
> >> > > > >>> native plugin for the crypto :(
> >> > > > >>> >
> >> > > > >>> > --
> >> > > > >>> > tommy-carlos williams
> >> > > > >>> >
> >> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com
> )
> >> > > wrote:
> >> > > > >>> >
> >> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
> >> > > contain
> >> > > > >>> > the loadFileURL:readAccessURL: selector that we are all
> >> waiting
> >> > for
> >> > > > >>> > :'(
> >> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> >> > > > >>>
> >> > > > >>
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by tommy-carlos williams <to...@devgeeks.org>.
I would certainly like to see a test to see what the lag is like...
--
tommy-carlos williams
On 11 June 2015 at 02:01:35, Shazron (shazron@gmail.com) wrote:
Safari View Controller video:
https://developer.apple.com/videos/wwdc/2015/?id=504
What's New in Web Development in WebKit and Safari video:
https://developer.apple.com/videos/wwdc/2015/?id=501
On Tue, Jun 9, 2015 at 3:59 PM, Shazron <sh...@gmail.com> wrote:
> I definitely will watch.
> Just read about ODR
> https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1
>
> So we could still use the copy method (fast, small app bundle) and have a
> solution in Cordova for ODR for app bundles that are huge. For example, in
> the CLI prepare step.
>
> Of course this won't be a universal solution and is more complicated.
>
> On Tuesday, June 9, 2015, Carlos Santana <cs...@gmail.com> wrote:
>
>> What do we loose, I just attended the session.
>> I think for most uses is a win at least in the security aspect
>> Watch the session when the video is available and we can discuss later.
>>
>> On Tue, Jun 9, 2015 at 1:23 PM Shazron <sh...@gmail.com> wrote:
>>
>> > We could use it for InAppBrowser but we might lose some features that we
>> > have possibly.
>> >
>> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
>> urls
>> > in Library and Documents, but not the app bundle.
>> > https://twitter.com/wkwebview/status/608359163299819521
>> >
>> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com>
>> > wrote:
>> >
>> > > Yay !
>> > > There is also a new Safari View Controller, don't know if it's
>> applicable
>> > > to replace wkwebview but at least I think it can be use to build the
>> next
>> > > gen inappbrowser since its beats a makeup in iOS anyway.
>> > >
>> > > The session is in 30 minutes so I'm planning attending.
>> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
>> > >
>> > > > There is a WWDC session: "Safari Extensibility: Content Blocking and
>> > > Shared
>> > > > Links". So I'm hopeful for whitelisting
>> > > >
>> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
>> > > >
>> > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584
>> > > > >
>> > > > >
>> > > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
>> > > > >
>> > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages
>> > from
>> > > > >> file:// urls
>> > https://twitter.com/wkwebview/status/608002548151119872
>> > > > >>
>> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com>
>> wrote:
>> > > > >>
>> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade
>> I
>> > > > >>> suppose for your dev machines and build servers...
>> > > > >>>
>> > > > >>>
>> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
>> > > > >>> <to...@devgeeks.org> wrote:
>> > > > >>> > Oh, FFS.
>> > > > >>> >
>> > > > >>> > I give up on Apple solving this, personally. Most apps don’t
>> > > > >>> *actually* need it (they think they do, but they don’t). I am
>> going
>> > > to
>> > > > find
>> > > > >>> another way to solve it for our apps… maybe I will actually
>> have to
>> > > > write a
>> > > > >>> native plugin for the crypto :(
>> > > > >>> >
>> > > > >>> > --
>> > > > >>> > tommy-carlos williams
>> > > > >>> >
>> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com)
>> > > wrote:
>> > > > >>> >
>> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
>> > > contain
>> > > > >>> > the loadFileURL:readAccessURL: selector that we are all
>> waiting
>> > for
>> > > > >>> > :'(
>> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > >
>> > >
>> >
>>
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Safari View Controller video:
https://developer.apple.com/videos/wwdc/2015/?id=504
What's New in Web Development in WebKit and Safari video:
https://developer.apple.com/videos/wwdc/2015/?id=501
On Tue, Jun 9, 2015 at 3:59 PM, Shazron <sh...@gmail.com> wrote:
> I definitely will watch.
> Just read about ODR
> https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1
>
> So we could still use the copy method (fast, small app bundle) and have a
> solution in Cordova for ODR for app bundles that are huge. For example, in
> the CLI prepare step.
>
> Of course this won't be a universal solution and is more complicated.
>
> On Tuesday, June 9, 2015, Carlos Santana <cs...@gmail.com> wrote:
>
>> What do we loose, I just attended the session.
>> I think for most uses is a win at least in the security aspect
>> Watch the session when the video is available and we can discuss later.
>>
>> On Tue, Jun 9, 2015 at 1:23 PM Shazron <sh...@gmail.com> wrote:
>>
>> > We could use it for InAppBrowser but we might lose some features that we
>> > have possibly.
>> >
>> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
>> urls
>> > in Library and Documents, but not the app bundle.
>> > https://twitter.com/wkwebview/status/608359163299819521
>> >
>> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com>
>> > wrote:
>> >
>> > > Yay !
>> > > There is also a new Safari View Controller, don't know if it's
>> applicable
>> > > to replace wkwebview but at least I think it can be use to build the
>> next
>> > > gen inappbrowser since its beats a makeup in iOS anyway.
>> > >
>> > > The session is in 30 minutes so I'm planning attending.
>> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
>> > >
>> > > > There is a WWDC session: "Safari Extensibility: Content Blocking and
>> > > Shared
>> > > > Links". So I'm hopeful for whitelisting
>> > > >
>> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
>> > > >
>> > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584
>> > > > >
>> > > > >
>> > > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
>> > > > >
>> > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages
>> > from
>> > > > >> file:// urls
>> > https://twitter.com/wkwebview/status/608002548151119872
>> > > > >>
>> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com>
>> wrote:
>> > > > >>
>> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade
>> I
>> > > > >>> suppose for your dev machines and build servers...
>> > > > >>>
>> > > > >>>
>> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
>> > > > >>> <to...@devgeeks.org> wrote:
>> > > > >>> > Oh, FFS.
>> > > > >>> >
>> > > > >>> > I give up on Apple solving this, personally. Most apps don’t
>> > > > >>> *actually* need it (they think they do, but they don’t). I am
>> going
>> > > to
>> > > > find
>> > > > >>> another way to solve it for our apps… maybe I will actually
>> have to
>> > > > write a
>> > > > >>> native plugin for the crypto :(
>> > > > >>> >
>> > > > >>> > --
>> > > > >>> > tommy-carlos williams
>> > > > >>> >
>> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com)
>> > > wrote:
>> > > > >>> >
>> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
>> > > contain
>> > > > >>> > the loadFileURL:readAccessURL: selector that we are all
>> waiting
>> > for
>> > > > >>> > :'(
>> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > >
>> > >
>> >
>>
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
I definitely will watch.
Just read about ODR
https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1
So we could still use the copy method (fast, small app bundle) and have a
solution in Cordova for ODR for app bundles that are huge. For example, in
the CLI prepare step.
Of course this won't be a universal solution and is more complicated.
On Tuesday, June 9, 2015, Carlos Santana <cs...@gmail.com> wrote:
> What do we loose, I just attended the session.
> I think for most uses is a win at least in the security aspect
> Watch the session when the video is available and we can discuss later.
>
> On Tue, Jun 9, 2015 at 1:23 PM Shazron <shazron@gmail.com <javascript:;>>
> wrote:
>
> > We could use it for InAppBrowser but we might lose some features that we
> > have possibly.
> >
> > Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
> urls
> > in Library and Documents, but not the app bundle.
> > https://twitter.com/wkwebview/status/608359163299819521
> >
> > On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <csantana23@gmail.com
> <javascript:;>>
> > wrote:
> >
> > > Yay !
> > > There is also a new Safari View Controller, don't know if it's
> applicable
> > > to replace wkwebview but at least I think it can be use to build the
> next
> > > gen inappbrowser since its beats a makeup in iOS anyway.
> > >
> > > The session is in 30 minutes so I'm planning attending.
> > > On Mon, Jun 8, 2015 at 2:33 PM Shazron <shazron@gmail.com
> <javascript:;>> wrote:
> > >
> > > > There is a WWDC session: "Safari Extensibility: Content Blocking and
> > > Shared
> > > > Links". So I'm hopeful for whitelisting
> > > >
> > > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <shazron@gmail.com
> <javascript:;>> wrote:
> > > >
> > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584
> > > > >
> > > > >
> > > > > On Monday, June 8, 2015, Shazron <shazron@gmail.com <javascript:;>>
> wrote:
> > > > >
> > > > >> Cordova developers rejoice, iOS 9 includes the API to load pages
> > from
> > > > >> file:// urls
> > https://twitter.com/wkwebview/status/608002548151119872
> > > > >>
> > > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <shazron@gmail.com
> <javascript:;>> wrote:
> > > > >>
> > > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> > > > >>> suppose for your dev machines and build servers...
> > > > >>>
> > > > >>>
> > > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> > > > >>> <tommy@devgeeks.org <javascript:;>> wrote:
> > > > >>> > Oh, FFS.
> > > > >>> >
> > > > >>> > I give up on Apple solving this, personally. Most apps don’t
> > > > >>> *actually* need it (they think they do, but they don’t). I am
> going
> > > to
> > > > find
> > > > >>> another way to solve it for our apps… maybe I will actually have
> to
> > > > write a
> > > > >>> native plugin for the crypto :(
> > > > >>> >
> > > > >>> > --
> > > > >>> > tommy-carlos williams
> > > > >>> >
> > > > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com
> <javascript:;>)
> > > wrote:
> > > > >>> >
> > > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
> > > contain
> > > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting
> > for
> > > > >>> > :'(
> > > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Carlos Santana <cs...@gmail.com>.
What do we loose, I just attended the session.
I think for most uses is a win at least in the security aspect
Watch the session when the video is available and we can discuss later.
On Tue, Jun 9, 2015 at 1:23 PM Shazron <sh...@gmail.com> wrote:
> We could use it for InAppBrowser but we might lose some features that we
> have possibly.
>
> Anyways, one piece of bad news for WKWebView iOS 9 - you can load file urls
> in Library and Documents, but not the app bundle.
> https://twitter.com/wkwebview/status/608359163299819521
>
> On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com>
> wrote:
>
> > Yay !
> > There is also a new Safari View Controller, don't know if it's applicable
> > to replace wkwebview but at least I think it can be use to build the next
> > gen inappbrowser since its beats a makeup in iOS anyway.
> >
> > The session is in 30 minutes so I'm planning attending.
> > On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> >
> > > There is a WWDC session: "Safari Extensibility: Content Blocking and
> > Shared
> > > Links". So I'm hopeful for whitelisting
> > >
> > > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > > > Moar news https://twitter.com/wkwebview/status/608005652720451584
> > > >
> > > >
> > > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> > > >
> > > >> Cordova developers rejoice, iOS 9 includes the API to load pages
> from
> > > >> file:// urls
> https://twitter.com/wkwebview/status/608002548151119872
> > > >>
> > > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
> > > >>
> > > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> > > >>> suppose for your dev machines and build servers...
> > > >>>
> > > >>>
> > > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> > > >>> <to...@devgeeks.org> wrote:
> > > >>> > Oh, FFS.
> > > >>> >
> > > >>> > I give up on Apple solving this, personally. Most apps don’t
> > > >>> *actually* need it (they think they do, but they don’t). I am going
> > to
> > > find
> > > >>> another way to solve it for our apps… maybe I will actually have to
> > > write a
> > > >>> native plugin for the crypto :(
> > > >>> >
> > > >>> > --
> > > >>> > tommy-carlos williams
> > > >>> >
> > > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com)
> > wrote:
> > > >>> >
> > > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
> > contain
> > > >>> > the loadFileURL:readAccessURL: selector that we are all waiting
> for
> > > >>> > :'(
> > > >>> > https://twitter.com/wkwebview/status/564865657225756672
> > > >>>
> > > >>
> > > >>
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
We could use it for InAppBrowser but we might lose some features that we
have possibly.
Anyways, one piece of bad news for WKWebView iOS 9 - you can load file urls
in Library and Documents, but not the app bundle.
https://twitter.com/wkwebview/status/608359163299819521
On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana <cs...@gmail.com> wrote:
> Yay !
> There is also a new Safari View Controller, don't know if it's applicable
> to replace wkwebview but at least I think it can be use to build the next
> gen inappbrowser since its beats a makeup in iOS anyway.
>
> The session is in 30 minutes so I'm planning attending.
> On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
>
> > There is a WWDC session: "Safari Extensibility: Content Blocking and
> Shared
> > Links". So I'm hopeful for whitelisting
> >
> > On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > Moar news https://twitter.com/wkwebview/status/608005652720451584
> > >
> > >
> > > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> > >
> > >> Cordova developers rejoice, iOS 9 includes the API to load pages from
> > >> file:// urls https://twitter.com/wkwebview/status/608002548151119872
> > >>
> > >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
> > >>
> > >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> > >>> suppose for your dev machines and build servers...
> > >>>
> > >>>
> > >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> > >>> <to...@devgeeks.org> wrote:
> > >>> > Oh, FFS.
> > >>> >
> > >>> > I give up on Apple solving this, personally. Most apps don’t
> > >>> *actually* need it (they think they do, but they don’t). I am going
> to
> > find
> > >>> another way to solve it for our apps… maybe I will actually have to
> > write a
> > >>> native plugin for the crypto :(
> > >>> >
> > >>> > --
> > >>> > tommy-carlos williams
> > >>> >
> > >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com)
> wrote:
> > >>> >
> > >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
> contain
> > >>> > the loadFileURL:readAccessURL: selector that we are all waiting for
> > >>> > :'(
> > >>> > https://twitter.com/wkwebview/status/564865657225756672
> > >>>
> > >>
> > >>
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Carlos Santana <cs...@gmail.com>.
Yay !
There is also a new Safari View Controller, don't know if it's applicable
to replace wkwebview but at least I think it can be use to build the next
gen inappbrowser since its beats a makeup in iOS anyway.
The session is in 30 minutes so I'm planning attending.
On Mon, Jun 8, 2015 at 2:33 PM Shazron <sh...@gmail.com> wrote:
> There is a WWDC session: "Safari Extensibility: Content Blocking and Shared
> Links". So I'm hopeful for whitelisting
>
> On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
>
> > Moar news https://twitter.com/wkwebview/status/608005652720451584
> >
> >
> > On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> >
> >> Cordova developers rejoice, iOS 9 includes the API to load pages from
> >> file:// urls https://twitter.com/wkwebview/status/608002548151119872
> >>
> >> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
> >>
> >>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> >>> suppose for your dev machines and build servers...
> >>>
> >>>
> >>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> >>> <to...@devgeeks.org> wrote:
> >>> > Oh, FFS.
> >>> >
> >>> > I give up on Apple solving this, personally. Most apps don’t
> >>> *actually* need it (they think they do, but they don’t). I am going to
> find
> >>> another way to solve it for our apps… maybe I will actually have to
> write a
> >>> native plugin for the crypto :(
> >>> >
> >>> > --
> >>> > tommy-carlos williams
> >>> >
> >>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com) wrote:
> >>> >
> >>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
> >>> > the loadFileURL:readAccessURL: selector that we are all waiting for
> >>> > :'(
> >>> > https://twitter.com/wkwebview/status/564865657225756672
> >>>
> >>
> >>
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
There is a WWDC session: "Safari Extensibility: Content Blocking and Shared
Links". So I'm hopeful for whitelisting
On Mon, Jun 8, 2015 at 1:22 PM, Shazron <sh...@gmail.com> wrote:
> Moar news https://twitter.com/wkwebview/status/608005652720451584
>
>
> On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
>
>> Cordova developers rejoice, iOS 9 includes the API to load pages from
>> file:// urls https://twitter.com/wkwebview/status/608002548151119872
>>
>> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
>>
>>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
>>> suppose for your dev machines and build servers...
>>>
>>>
>>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
>>> <to...@devgeeks.org> wrote:
>>> > Oh, FFS.
>>> >
>>> > I give up on Apple solving this, personally. Most apps don’t
>>> *actually* need it (they think they do, but they don’t). I am going to find
>>> another way to solve it for our apps… maybe I will actually have to write a
>>> native plugin for the crypto :(
>>> >
>>> > --
>>> > tommy-carlos williams
>>> >
>>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com) wrote:
>>> >
>>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
>>> > the loadFileURL:readAccessURL: selector that we are all waiting for
>>> > :'(
>>> > https://twitter.com/wkwebview/status/564865657225756672
>>>
>>
>>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Moar news https://twitter.com/wkwebview/status/608005652720451584
On Monday, June 8, 2015, Shazron <sh...@gmail.com> wrote:
> Cordova developers rejoice, iOS 9 includes the API to load pages from
> file:// urls https://twitter.com/wkwebview/status/608002548151119872
>
> On Mon, Feb 9, 2015 at 2:19 PM, Shazron <shazron@gmail.com
> <javascript:_e(%7B%7D,'cvml','shazron@gmail.com');>> wrote:
>
>> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
>> suppose for your dev machines and build servers...
>>
>>
>> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
>> <tommy@devgeeks.org <javascript:_e(%7B%7D,'cvml','tommy@devgeeks.org');>>
>> wrote:
>> > Oh, FFS.
>> >
>> > I give up on Apple solving this, personally. Most apps don’t *actually*
>> need it (they think they do, but they don’t). I am going to find another
>> way to solve it for our apps… maybe I will actually have to write a native
>> plugin for the crypto :(
>> >
>> > --
>> > tommy-carlos williams
>> >
>> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com
>> <javascript:_e(%7B%7D,'cvml','shazron@gmail.com');>) wrote:
>> >
>> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
>> > the loadFileURL:readAccessURL: selector that we are all waiting for
>> > :'(
>> > https://twitter.com/wkwebview/status/564865657225756672
>>
>
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Cordova developers rejoice, iOS 9 includes the API to load pages from
file:// urls https://twitter.com/wkwebview/status/608002548151119872
On Mon, Feb 9, 2015 at 2:19 PM, Shazron <sh...@gmail.com> wrote:
> Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
> suppose for your dev machines and build servers...
>
>
> On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
> <to...@devgeeks.org> wrote:
> > Oh, FFS.
> >
> > I give up on Apple solving this, personally. Most apps don’t *actually*
> need it (they think they do, but they don’t). I am going to find another
> way to solve it for our apps… maybe I will actually have to write a native
> plugin for the crypto :(
> >
> > --
> > tommy-carlos williams
> >
> > On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com) wrote:
> >
> > In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
> > the loadFileURL:readAccessURL: selector that we are all waiting for
> > :'(
> > https://twitter.com/wkwebview/status/564865657225756672
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
suppose for your dev machines and build servers...
On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
<to...@devgeeks.org> wrote:
> Oh, FFS.
>
> I give up on Apple solving this, personally. Most apps don’t *actually* need it (they think they do, but they don’t). I am going to find another way to solve it for our apps… maybe I will actually have to write a native plugin for the crypto :(
>
> --
> tommy-carlos williams
>
> On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com) wrote:
>
> In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
> the loadFileURL:readAccessURL: selector that we are all waiting for
> :'(
> https://twitter.com/wkwebview/status/564865657225756672
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [iOS 8] WKWebView moving forward
Posted by tommy-carlos williams <to...@devgeeks.org>.
Oh, FFS.
I give up on Apple solving this, personally. Most apps don’t *actually* need it (they think they do, but they don’t). I am going to find another way to solve it for our apps… maybe I will actually have to write a native plugin for the crypto :(
--
tommy-carlos williams
On 10 February 2015 at 08:18:31, Shazron (shazron@gmail.com) wrote:
In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
the loadFileURL:readAccessURL: selector that we are all waiting for
:'(
https://twitter.com/wkwebview/status/564865657225756672
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Some have been asking -- why not use that Telerik plugin?
1. Swizzling will potentially come with some headaches in the future.
As it is currently, the Telerik plugin swaps implementations for an
AppDelegate function. So whatever changes we have in the AppDelegate
function in the future, it will be lost. The plugin could call the old
implementation as well (it does not do so currently), but of course
this could create problems as is. This would be hard to maintain with
potential future changes.
2. The Telerik plugin will not work if you have any file:// url
references when using the core Camera and File plugins. The pluggable
webview (wkwebview-engine) and local httpserver proposed will have a
solution for this (still a work in progress, needs testing). The
Telerik plugin can of course copy from our proposed code to solve this
problem.
Blog post upcoming, I think, where I can just gather all info
regarding the planned work -- for the general public and not just us
devs.
On Mon, Feb 9, 2015 at 11:23 AM, Shazron <sh...@gmail.com> wrote:
> Darryl: That plugin, based on inspection, is based off my work in
> progress code (also used to be based off tmp loading, but now uses the
> same httpserver method). The major thing I can see they added was
> swizzling an AppDelegate method so it can work on any 3.x cordova-ios.
>
> In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
> the loadFileURL:readAccessURL: selector that we are all waiting for
> :'(
> https://twitter.com/wkwebview/status/564865657225756672
>
> On Wed, Dec 10, 2014 at 10:28 PM, Darryl Pogue <dv...@gmail.com> wrote:
>> On 10 December 2014 at 22:20, Ally Ogilvie <ao...@wizcorp.jp> wrote:
>>>
>>> @Brian it's a dark road down that way..
>>>
>>> However, the guys at Ludei patched WKWebView and released "WebView+ for
>>> iOS" but have not released the source code :(
>>> https://github.com/ludei/webview-plus-ios/tree/master/ios/Release-iphoneos
>>>
>>
>> There's also a Telerik plugin for WkWebView support:
>> https://github.com/Telerik-Verified-Plugins/WKWebView
>>
>> It seems to do roughly the same thing that Shazron's been working on
>> (serving from a local HTTP server rather than from file).
>>
>> ---------------------------------------------------------------------
>> 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
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Darryl: That plugin, based on inspection, is based off my work in
progress code (also used to be based off tmp loading, but now uses the
same httpserver method). The major thing I can see they added was
swizzling an AppDelegate method so it can work on any 3.x cordova-ios.
In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not* contain
the loadFileURL:readAccessURL: selector that we are all waiting for
:'(
https://twitter.com/wkwebview/status/564865657225756672
On Wed, Dec 10, 2014 at 10:28 PM, Darryl Pogue <dv...@gmail.com> wrote:
> On 10 December 2014 at 22:20, Ally Ogilvie <ao...@wizcorp.jp> wrote:
>>
>> @Brian it's a dark road down that way..
>>
>> However, the guys at Ludei patched WKWebView and released "WebView+ for
>> iOS" but have not released the source code :(
>> https://github.com/ludei/webview-plus-ios/tree/master/ios/Release-iphoneos
>>
>
> There's also a Telerik plugin for WkWebView support:
> https://github.com/Telerik-Verified-Plugins/WKWebView
>
> It seems to do roughly the same thing that Shazron's been working on
> (serving from a local HTTP server rather than from file).
>
> ---------------------------------------------------------------------
> 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
Re: [iOS 8] WKWebView moving forward
Posted by Darryl Pogue <dv...@gmail.com>.
On 10 December 2014 at 22:20, Ally Ogilvie <ao...@wizcorp.jp> wrote:
>
> @Brian it's a dark road down that way..
>
> However, the guys at Ludei patched WKWebView and released "WebView+ for
> iOS" but have not released the source code :(
> https://github.com/ludei/webview-plus-ios/tree/master/ios/Release-iphoneos
>
There's also a Telerik plugin for WkWebView support:
https://github.com/Telerik-Verified-Plugins/WKWebView
It seems to do roughly the same thing that Shazron's been working on
(serving from a local HTTP server rather than from file).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [iOS 8] WKWebView moving forward
Posted by Ally Ogilvie <ao...@wizcorp.jp>.
@Brian it's a dark road down that way..
However, the guys at Ludei patched WKWebView and released "WebView+ for
iOS" but have not released the source code :(
https://github.com/ludei/webview-plus-ios/tree/master/ios/Release-iphoneos
We are playing around over here too, but have limited corp backing right
now to do a full port.
We may add WebView+ simply as a replacement to UIWebView in our
WizViewManager plugin.
The WebView+ is installable as a Cordova plugin but you must use the
cocoonjs-cli.
On Thu, Dec 11, 2014 at 8:47 AM, Brian LeRoux <b...@brian.io> wrote:
> so, it appears wkwebview itself is open source [1] …well outside my comfort
> zone but feasible we fix these things ourselves?
>
> [1]
>
> https://github.com/WebKit/webkit/blob/0190dd5b8c0272beaa705dbc10863a84a3e6af5e/Source/WebKit2/UIProcess/API/Cocoa/WKWebView.h
>
>
>
> On Wed, Dec 10, 2014 at 3:18 PM, Shazron <sh...@gmail.com> wrote:
>
> > No dice in iOS 8.2b2 that was released today:
> >
> >
> https://issues.apache.org/jira/browse/CB-7090?focusedCommentId=14241546&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14241546
> >
> > On Thu, Nov 20, 2014 at 1:37 PM, Shazron <sh...@gmail.com> wrote:
> > > I updated https://issues.apache.org/jira/browse/CB-8032 with my
> revised
> > > approach. I'd like to move on with this as soon as possible.
> > >
> > > Let's continue the discussion there.
> > >
> > > On Wed, Nov 19, 2014 at 1:14 PM, Homer, Tony <to...@intel.com>
> > wrote:
> > >>
> > >> Ugh. Thanks for the additional information, Shazron.
> > >>
> > >> I had previously proposed adding a hook (by which I meant a delegate
> > >> method) to CDVPluginResult (that would be called from -
> > >> (CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
> > >> message:(id)theMessage) so that LocalWebServer could (blindly) detect
> > and
> > >> transform urls.
> > >>
> > >> It seems like it would help with this case, but not be generally
> useful
> > >> for anything else…
> > >>
> > >> Tony
> > >>
> > >> On 11/19/14, 3:23 PM, "Shazron" <sh...@gmail.com> wrote:
> > >>
> > >> >Ideally a general solution like you proposed should work, but I
> forgot
> > to
> > >> >mention that in this case, since we are talking about WKWebView, we
> > can't
> > >> >use NSURLProtocol since it is not supported in that framework [1][2]
> > >> >
> > >> >The only other general way I can see is to require explicit support
> in
> > >> >plugins, they may have to call something in the
> > >> >commandDelegate/viewController to transform a url, that can be set by
> > >> >another plugin, in this case LocalWebServer (my revised proposal was
> a
> > >> >'push' this is a 'pull').
> > >> >
> > >> >
> > >> >[1] https://issues.apache.org/jira/browse/CB-7049
> > >> >[2] http://www.openradar.me/18492325
> > >> >
> > >> >On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com>
> > >> >wrote:
> > >> >
> > >> >> If we are just talking about CB-8032, then I can see that this
> > approach
> > >> >>is
> > >> >> cleaner for the file plugin.
> > >> >>
> > >> >> Regarding local web server plugin in general - what about other
> > plugins
> > >> >> such as camera?
> > >> >> Doesn¹t there need to be a general solution that will provide
> > >> >> compatibility between local web server plugin and any plugin that
> > >> >>returns
> > >> >> a file protocol URL?
> > >> >>
> > >> >> Tony
> > >> >>
> > >> >> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
> > >> >>
> > >> >> >I commented on Ian's comment on CB-8032:
> > >> >> >
> > >> >>
> > >>
> > >> >> >>
> >
> https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p
> > >> >>a
> > >> >>
> > >>
> > >> >>>
> >
> >>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
> > >> >>>en
> > >> >> >t-14216403
> > >> >> >
> > >> >> >My goal was to have a loose coupling of this functionality
> (CDVFile
> > >> >>need
> > >> >> >not know about LocalWebServer at all) -- and Ian's comment of this
> > >> >>change
> > >> >> >is that would impact all CDVFileSystem instances makes this not an
> > >> >>ideal
> > >> >> >solution, what if you have two Cordova WebView instances, etc.
> > >> >> >
> > >> >> >My revised proposal requires CDVFileSystem to have a delegate that
> > can
> > >> >>be
> > >> >> >set. Any class can set it to override the nativeURL behaviour, and
> > >> >> >CDVFileSystem will call this method in the delegate if available.
> It
> > >> >> >achieves the same goal without the potentially undefined behaviour
> > of
> > >> >>an
> > >> >> >Obj-C Category.
> > >> >> >
> > >> >> >The LocalWebServer gets the currently installed File plugin,
> > >> >> > enumerates
> > >> >> >all
> > >> >> >available filesystems, and sets this delegate on each, to its own
> > >> >> >implementation.
> > >> >> >
> > >> >> >Tony - I think this is approach is cleaner, and is more
> > maintainable.
> > >> >> >
> > >> >> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <
> > iclelland@chromium.org>
> > >> >> >wrote:
> > >> >> >
> > >> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <purplecabbage@gmail.com
> >
> > >> >>wrote:
> > >> >> >>
> > >> >> >> > Shaz's solution has less impact and seems more elegant.
> > >> >> >> >
> > >> >> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)])
> {
> > >> >> >> >
> > >> >> >> > If no-one ( generically ) has provided the nativeFullPath
> > method,
> > >> >>then
> > >> >> >> use
> > >> >> >> > it as is, otherwise call it.
> > >> >> >> > No need for any (direct) dependency between File +
> LocalServer.
> > >> >> >> >
> > >> >> >>
> > >> >> >> My first instinct, looking at the code, was that it was wrong,
> > >> >>exactly
> > >> >> >> because there *is* a dependency. You don't normally add code to
> a
> > >> >>base
> > >> >> >> class to change its behaviour when there is a category defined
> on
> > >> >> >> it.
> > >> >> >> Normally that goes the other way: when you add a category to a
> > base
> > >> >> >>class,
> > >> >> >> all of the code that's relevant to that category is *in the
> > >> >>category*,
> > >> >> >>and
> > >> >> >> the base class needs to know nothing at all about it, including
> > its
> > >> >> >> existence.
> > >> >> >>
> > >> >> >> As I said in the PR, it may be that this really is the cleanest
> > and
> > >> >>best
> > >> >> >> way to go forward with this; I just wanted to have this
> discussion
> > >> >>and
> > >> >> >> figure it out with the community before committing to any
> > >> >> >> hard-to-change-later technical debt. It does become an API
> > surface,
> > >> >>and
> > >> >> >>we
> > >> >> >> will have to maintain whatever we adopt.
> > >> >> >>
> > >> >> >> Ian
> > >> >> >>
> > >> >> >>
> > >> >> >> >
> > >> >> >> > @purplecabbage
> > >> >> >> > risingj.com
> > >> >> >> >
> > >> >> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
> > >> >><agrieve@chromium.org
> > >> >> >
> > >> >> >> > wrote:
> > >> >> >> >
> > >> >> >> > > Having the localserver plugin add behaviour to file plugin
> > feels
> > >> >> >>like
> > >> >> >> the
> > >> >> >> > > dependency is in the wrong direction to me.
> > >> >> >> > >
> > >> >> >> > > How about having CDVFile.m do something like:
> > >> >> >> > >
> > >> >> >> > > CDVPlugin* p = [commandDelegate
> > >> >>getCommandInstance:@"LocalServer"];
> > >> >> >> > > if (p != nil) {
> > >> >> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
> > >> >> >>declaration
> > >> >> >> to
> > >> >> >> > > make this not complain about unrecognized selector
> > >> >> >> > > }
> > >> >> >> > >
> > >> >> >> > > Would probably also need an "untransformURL" to go the other
> > >> >> >>direction
> > >> >> >> as
> > >> >> >> > > well.
> > >> >> >> > >
> > >> >> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <
> shazron@gmail.com>
> > >> >> wrote:
> > >> >> >> > >
> > >> >> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with
> > pull
> > >> >> >> request
> > >> >> >> > > > included.
> > >> >> >> > > >
> > >> >> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <
> shazron@gmail.com
> > >
> > >> >> >>wrote:
> > >> >> >> > > >
> > >> >> >> > > > > Sorry I should have looked into the File API code first
> > (no
> > >> >> >> > JavaScript
> > >> >> >> > > > > changes, that would not work).
> > >> >> >> > > > >
> > >> >> >> > > > > Essentially I need to "override" this line from my
> plugin:
> > >> >> >> > > > >
> > >> >> >> > > >
> > >> >> >> > > https://github.com/apache/cordova-plugin-file/blob/
> > >> >> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
> > >> >> >> > CDVAssetLibraryFilesystem.m#L74
> > >> >> >> > > > > (plus the CDVLocalFileSystem equivalent).
> > >> >> >> > > > >
> > >> >> >> > > > > Since Obj-C categories can't really "override" methods
> > >> >>(behavior
> > >> >> >> > > > > undefined), and I don't want to do some runtime swap
> > >> >> >>implementation
> > >> >> >> > > > voodoo,
> > >> >> >> > > > > I would replace the line above with something like:
> > >> >> >> > > > >
> > >> >> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
> > >> >> >> > > > > "assets-library:/%@",fullPath];
> > >> >> >> > > > > if ([self respondsToSelector:@selector
> (nativeFullPath:)])
> > {
> > >> >>//
> > >> >> >> some
> > >> >> >> > > > > unique selector name perhaps
> > >> >> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this
> > >> >> >> > > > > code
> > >> >> >>won't
> > >> >> >> > > > > compile, pseudo-code for now. Will call my category
> method
> > >> >> >>defined
> > >> >> >> in
> > >> >> >> > > my
> > >> >> >> > > > > plugin for CDVAssetLibraryFileSystem
> > >> >> >> > > > > }
> > >> >> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
> > >> >> >> > > > >
> > >> >> >> > > > > Backwards compatible.
> > >> >> >> > > > >
> > >> >> >> > > > >
> > >> >> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <
> > shazron@gmail.com>
> > >> >> >> wrote:
> > >> >> >> > > > >
> > >> >> >> > > > >> Local Web Server Checklist:
> > >> >> >> > > > >> 1. We have random port usage
> > >> >> >> > > > >> 2. We have the token/cookie check
> > >> >> >> > > > >> 3. We have the localhost check
> > >> >> >> > > > >> 4. The app is now installed under
> > >> >>http://localhost:RANDOM_PORT
> > >> >> >> /www/
> > >> >> >> > > > >>
> > >> >> >> > > > >> It'll be easy (relatively) to add support for:
> > >> >> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
> > >> >> >> > > > >> http://localhost:RANDOM_PORT/file-system/
> > >> >> >> > > > >>
> > >> >> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm
> > >> >>thinking
> > >> >> >>of
> > >> >> >> > some
> > >> >> >> > > > >> runtime 'magic' in the local web server where it
> detects
> > >> >> >> > > > >> the
> > >> >> >>File
> > >> >> >> > > > plugin,
> > >> >> >> > > > >> and change the implementation of FileEntry.toURL() (or
> > >> >>through
> > >> >> >> > > injecting
> > >> >> >> > > > >> JavaScript, probably easier).
> > >> >> >> > > > >>
> > >> >> >> > > > >>
> > >> >> >> > > > >> 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
> > >> >><sh...@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
> >
> >
>
--
<http://www.wizcorp.jp/>Ally Ogilvie
Lead Developer - MobDev. | Wizcorp Inc. <http://www.wizcorp.jp/>
------------------------------
TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 | Website
<http://www.wizcorp.jp/> | Twitter <https://twitter.com/Wizcorp> | Facebook
<http://www.facebook.com/Wizcorp> | LinkedIn
<http://www.linkedin.com/company/wizcorp>
Re: [iOS 8] WKWebView moving forward
Posted by Brian LeRoux <b...@brian.io>.
so, it appears wkwebview itself is open source [1] …well outside my comfort
zone but feasible we fix these things ourselves?
[1]
https://github.com/WebKit/webkit/blob/0190dd5b8c0272beaa705dbc10863a84a3e6af5e/Source/WebKit2/UIProcess/API/Cocoa/WKWebView.h
On Wed, Dec 10, 2014 at 3:18 PM, Shazron <sh...@gmail.com> wrote:
> No dice in iOS 8.2b2 that was released today:
>
> https://issues.apache.org/jira/browse/CB-7090?focusedCommentId=14241546&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14241546
>
> On Thu, Nov 20, 2014 at 1:37 PM, Shazron <sh...@gmail.com> wrote:
> > I updated https://issues.apache.org/jira/browse/CB-8032 with my revised
> > approach. I'd like to move on with this as soon as possible.
> >
> > Let's continue the discussion there.
> >
> > On Wed, Nov 19, 2014 at 1:14 PM, Homer, Tony <to...@intel.com>
> wrote:
> >>
> >> Ugh. Thanks for the additional information, Shazron.
> >>
> >> I had previously proposed adding a hook (by which I meant a delegate
> >> method) to CDVPluginResult (that would be called from -
> >> (CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
> >> message:(id)theMessage) so that LocalWebServer could (blindly) detect
> and
> >> transform urls.
> >>
> >> It seems like it would help with this case, but not be generally useful
> >> for anything else…
> >>
> >> Tony
> >>
> >> On 11/19/14, 3:23 PM, "Shazron" <sh...@gmail.com> wrote:
> >>
> >> >Ideally a general solution like you proposed should work, but I forgot
> to
> >> >mention that in this case, since we are talking about WKWebView, we
> can't
> >> >use NSURLProtocol since it is not supported in that framework [1][2]
> >> >
> >> >The only other general way I can see is to require explicit support in
> >> >plugins, they may have to call something in the
> >> >commandDelegate/viewController to transform a url, that can be set by
> >> >another plugin, in this case LocalWebServer (my revised proposal was a
> >> >'push' this is a 'pull').
> >> >
> >> >
> >> >[1] https://issues.apache.org/jira/browse/CB-7049
> >> >[2] http://www.openradar.me/18492325
> >> >
> >> >On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com>
> >> >wrote:
> >> >
> >> >> If we are just talking about CB-8032, then I can see that this
> approach
> >> >>is
> >> >> cleaner for the file plugin.
> >> >>
> >> >> Regarding local web server plugin in general - what about other
> plugins
> >> >> such as camera?
> >> >> Doesn¹t there need to be a general solution that will provide
> >> >> compatibility between local web server plugin and any plugin that
> >> >>returns
> >> >> a file protocol URL?
> >> >>
> >> >> Tony
> >> >>
> >> >> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
> >> >>
> >> >> >I commented on Ian's comment on CB-8032:
> >> >> >
> >> >>
> >>
> >> >> >>
> https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p
> >> >>a
> >> >>
> >>
> >> >>>
> >>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
> >> >>>en
> >> >> >t-14216403
> >> >> >
> >> >> >My goal was to have a loose coupling of this functionality (CDVFile
> >> >>need
> >> >> >not know about LocalWebServer at all) -- and Ian's comment of this
> >> >>change
> >> >> >is that would impact all CDVFileSystem instances makes this not an
> >> >>ideal
> >> >> >solution, what if you have two Cordova WebView instances, etc.
> >> >> >
> >> >> >My revised proposal requires CDVFileSystem to have a delegate that
> can
> >> >>be
> >> >> >set. Any class can set it to override the nativeURL behaviour, and
> >> >> >CDVFileSystem will call this method in the delegate if available. It
> >> >> >achieves the same goal without the potentially undefined behaviour
> of
> >> >>an
> >> >> >Obj-C Category.
> >> >> >
> >> >> >The LocalWebServer gets the currently installed File plugin,
> >> >> > enumerates
> >> >> >all
> >> >> >available filesystems, and sets this delegate on each, to its own
> >> >> >implementation.
> >> >> >
> >> >> >Tony - I think this is approach is cleaner, and is more
> maintainable.
> >> >> >
> >> >> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <
> iclelland@chromium.org>
> >> >> >wrote:
> >> >> >
> >> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com>
> >> >>wrote:
> >> >> >>
> >> >> >> > Shaz's solution has less impact and seems more elegant.
> >> >> >> >
> >> >> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
> >> >> >> >
> >> >> >> > If no-one ( generically ) has provided the nativeFullPath
> method,
> >> >>then
> >> >> >> use
> >> >> >> > it as is, otherwise call it.
> >> >> >> > No need for any (direct) dependency between File + LocalServer.
> >> >> >> >
> >> >> >>
> >> >> >> My first instinct, looking at the code, was that it was wrong,
> >> >>exactly
> >> >> >> because there *is* a dependency. You don't normally add code to a
> >> >>base
> >> >> >> class to change its behaviour when there is a category defined on
> >> >> >> it.
> >> >> >> Normally that goes the other way: when you add a category to a
> base
> >> >> >>class,
> >> >> >> all of the code that's relevant to that category is *in the
> >> >>category*,
> >> >> >>and
> >> >> >> the base class needs to know nothing at all about it, including
> its
> >> >> >> existence.
> >> >> >>
> >> >> >> As I said in the PR, it may be that this really is the cleanest
> and
> >> >>best
> >> >> >> way to go forward with this; I just wanted to have this discussion
> >> >>and
> >> >> >> figure it out with the community before committing to any
> >> >> >> hard-to-change-later technical debt. It does become an API
> surface,
> >> >>and
> >> >> >>we
> >> >> >> will have to maintain whatever we adopt.
> >> >> >>
> >> >> >> Ian
> >> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> > @purplecabbage
> >> >> >> > risingj.com
> >> >> >> >
> >> >> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
> >> >><agrieve@chromium.org
> >> >> >
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> > > Having the localserver plugin add behaviour to file plugin
> feels
> >> >> >>like
> >> >> >> the
> >> >> >> > > dependency is in the wrong direction to me.
> >> >> >> > >
> >> >> >> > > How about having CDVFile.m do something like:
> >> >> >> > >
> >> >> >> > > CDVPlugin* p = [commandDelegate
> >> >>getCommandInstance:@"LocalServer"];
> >> >> >> > > if (p != nil) {
> >> >> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
> >> >> >>declaration
> >> >> >> to
> >> >> >> > > make this not complain about unrecognized selector
> >> >> >> > > }
> >> >> >> > >
> >> >> >> > > Would probably also need an "untransformURL" to go the other
> >> >> >>direction
> >> >> >> as
> >> >> >> > > well.
> >> >> >> > >
> >> >> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com>
> >> >> wrote:
> >> >> >> > >
> >> >> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with
> pull
> >> >> >> request
> >> >> >> > > > included.
> >> >> >> > > >
> >> >> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <shazron@gmail.com
> >
> >> >> >>wrote:
> >> >> >> > > >
> >> >> >> > > > > Sorry I should have looked into the File API code first
> (no
> >> >> >> > JavaScript
> >> >> >> > > > > changes, that would not work).
> >> >> >> > > > >
> >> >> >> > > > > Essentially I need to "override" this line from my plugin:
> >> >> >> > > > >
> >> >> >> > > >
> >> >> >> > > https://github.com/apache/cordova-plugin-file/blob/
> >> >> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
> >> >> >> > CDVAssetLibraryFilesystem.m#L74
> >> >> >> > > > > (plus the CDVLocalFileSystem equivalent).
> >> >> >> > > > >
> >> >> >> > > > > Since Obj-C categories can't really "override" methods
> >> >>(behavior
> >> >> >> > > > > undefined), and I don't want to do some runtime swap
> >> >> >>implementation
> >> >> >> > > > voodoo,
> >> >> >> > > > > I would replace the line above with something like:
> >> >> >> > > > >
> >> >> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
> >> >> >> > > > > "assets-library:/%@",fullPath];
> >> >> >> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)])
> {
> >> >>//
> >> >> >> some
> >> >> >> > > > > unique selector name perhaps
> >> >> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this
> >> >> >> > > > > code
> >> >> >>won't
> >> >> >> > > > > compile, pseudo-code for now. Will call my category method
> >> >> >>defined
> >> >> >> in
> >> >> >> > > my
> >> >> >> > > > > plugin for CDVAssetLibraryFileSystem
> >> >> >> > > > > }
> >> >> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
> >> >> >> > > > >
> >> >> >> > > > > Backwards compatible.
> >> >> >> > > > >
> >> >> >> > > > >
> >> >> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <
> shazron@gmail.com>
> >> >> >> wrote:
> >> >> >> > > > >
> >> >> >> > > > >> Local Web Server Checklist:
> >> >> >> > > > >> 1. We have random port usage
> >> >> >> > > > >> 2. We have the token/cookie check
> >> >> >> > > > >> 3. We have the localhost check
> >> >> >> > > > >> 4. The app is now installed under
> >> >>http://localhost:RANDOM_PORT
> >> >> >> /www/
> >> >> >> > > > >>
> >> >> >> > > > >> It'll be easy (relatively) to add support for:
> >> >> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
> >> >> >> > > > >> http://localhost:RANDOM_PORT/file-system/
> >> >> >> > > > >>
> >> >> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm
> >> >>thinking
> >> >> >>of
> >> >> >> > some
> >> >> >> > > > >> runtime 'magic' in the local web server where it detects
> >> >> >> > > > >> the
> >> >> >>File
> >> >> >> > > > plugin,
> >> >> >> > > > >> and change the implementation of FileEntry.toURL() (or
> >> >>through
> >> >> >> > > injecting
> >> >> >> > > > >> JavaScript, probably easier).
> >> >> >> > > > >>
> >> >> >> > > > >>
> >> >> >> > > > >> 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
> >> >><sh...@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
>
>
Re: [iOS 8] WKWebView moving forward
Posted by Andrew Grieve <ag...@chromium.org>.
Pretty sure they are saving it for the "and one last thing" part of the iOS
10 release :P
On Wed, Dec 10, 2014 at 6:18 PM, Shazron <sh...@gmail.com> wrote:
> No dice in iOS 8.2b2 that was released today:
>
> https://issues.apache.org/jira/browse/CB-7090?focusedCommentId=14241546&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14241546
>
> On Thu, Nov 20, 2014 at 1:37 PM, Shazron <sh...@gmail.com> wrote:
> > I updated https://issues.apache.org/jira/browse/CB-8032 with my revised
> > approach. I'd like to move on with this as soon as possible.
> >
> > Let's continue the discussion there.
> >
> > On Wed, Nov 19, 2014 at 1:14 PM, Homer, Tony <to...@intel.com>
> wrote:
> >>
> >> Ugh. Thanks for the additional information, Shazron.
> >>
> >> I had previously proposed adding a hook (by which I meant a delegate
> >> method) to CDVPluginResult (that would be called from -
> >> (CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
> >> message:(id)theMessage) so that LocalWebServer could (blindly) detect
> and
> >> transform urls.
> >>
> >> It seems like it would help with this case, but not be generally useful
> >> for anything else…
> >>
> >> Tony
> >>
> >> On 11/19/14, 3:23 PM, "Shazron" <sh...@gmail.com> wrote:
> >>
> >> >Ideally a general solution like you proposed should work, but I forgot
> to
> >> >mention that in this case, since we are talking about WKWebView, we
> can't
> >> >use NSURLProtocol since it is not supported in that framework [1][2]
> >> >
> >> >The only other general way I can see is to require explicit support in
> >> >plugins, they may have to call something in the
> >> >commandDelegate/viewController to transform a url, that can be set by
> >> >another plugin, in this case LocalWebServer (my revised proposal was a
> >> >'push' this is a 'pull').
> >> >
> >> >
> >> >[1] https://issues.apache.org/jira/browse/CB-7049
> >> >[2] http://www.openradar.me/18492325
> >> >
> >> >On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com>
> >> >wrote:
> >> >
> >> >> If we are just talking about CB-8032, then I can see that this
> approach
> >> >>is
> >> >> cleaner for the file plugin.
> >> >>
> >> >> Regarding local web server plugin in general - what about other
> plugins
> >> >> such as camera?
> >> >> Doesn¹t there need to be a general solution that will provide
> >> >> compatibility between local web server plugin and any plugin that
> >> >>returns
> >> >> a file protocol URL?
> >> >>
> >> >> Tony
> >> >>
> >> >> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
> >> >>
> >> >> >I commented on Ian's comment on CB-8032:
> >> >> >
> >> >>
> >>
> >> >> >>
> https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p
> >> >>a
> >> >>
> >>
> >> >>>
> >>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
> >> >>>en
> >> >> >t-14216403
> >> >> >
> >> >> >My goal was to have a loose coupling of this functionality (CDVFile
> >> >>need
> >> >> >not know about LocalWebServer at all) -- and Ian's comment of this
> >> >>change
> >> >> >is that would impact all CDVFileSystem instances makes this not an
> >> >>ideal
> >> >> >solution, what if you have two Cordova WebView instances, etc.
> >> >> >
> >> >> >My revised proposal requires CDVFileSystem to have a delegate that
> can
> >> >>be
> >> >> >set. Any class can set it to override the nativeURL behaviour, and
> >> >> >CDVFileSystem will call this method in the delegate if available. It
> >> >> >achieves the same goal without the potentially undefined behaviour
> of
> >> >>an
> >> >> >Obj-C Category.
> >> >> >
> >> >> >The LocalWebServer gets the currently installed File plugin,
> >> >> > enumerates
> >> >> >all
> >> >> >available filesystems, and sets this delegate on each, to its own
> >> >> >implementation.
> >> >> >
> >> >> >Tony - I think this is approach is cleaner, and is more
> maintainable.
> >> >> >
> >> >> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <
> iclelland@chromium.org>
> >> >> >wrote:
> >> >> >
> >> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com>
> >> >>wrote:
> >> >> >>
> >> >> >> > Shaz's solution has less impact and seems more elegant.
> >> >> >> >
> >> >> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
> >> >> >> >
> >> >> >> > If no-one ( generically ) has provided the nativeFullPath
> method,
> >> >>then
> >> >> >> use
> >> >> >> > it as is, otherwise call it.
> >> >> >> > No need for any (direct) dependency between File + LocalServer.
> >> >> >> >
> >> >> >>
> >> >> >> My first instinct, looking at the code, was that it was wrong,
> >> >>exactly
> >> >> >> because there *is* a dependency. You don't normally add code to a
> >> >>base
> >> >> >> class to change its behaviour when there is a category defined on
> >> >> >> it.
> >> >> >> Normally that goes the other way: when you add a category to a
> base
> >> >> >>class,
> >> >> >> all of the code that's relevant to that category is *in the
> >> >>category*,
> >> >> >>and
> >> >> >> the base class needs to know nothing at all about it, including
> its
> >> >> >> existence.
> >> >> >>
> >> >> >> As I said in the PR, it may be that this really is the cleanest
> and
> >> >>best
> >> >> >> way to go forward with this; I just wanted to have this discussion
> >> >>and
> >> >> >> figure it out with the community before committing to any
> >> >> >> hard-to-change-later technical debt. It does become an API
> surface,
> >> >>and
> >> >> >>we
> >> >> >> will have to maintain whatever we adopt.
> >> >> >>
> >> >> >> Ian
> >> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> > @purplecabbage
> >> >> >> > risingj.com
> >> >> >> >
> >> >> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
> >> >><agrieve@chromium.org
> >> >> >
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> > > Having the localserver plugin add behaviour to file plugin
> feels
> >> >> >>like
> >> >> >> the
> >> >> >> > > dependency is in the wrong direction to me.
> >> >> >> > >
> >> >> >> > > How about having CDVFile.m do something like:
> >> >> >> > >
> >> >> >> > > CDVPlugin* p = [commandDelegate
> >> >>getCommandInstance:@"LocalServer"];
> >> >> >> > > if (p != nil) {
> >> >> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
> >> >> >>declaration
> >> >> >> to
> >> >> >> > > make this not complain about unrecognized selector
> >> >> >> > > }
> >> >> >> > >
> >> >> >> > > Would probably also need an "untransformURL" to go the other
> >> >> >>direction
> >> >> >> as
> >> >> >> > > well.
> >> >> >> > >
> >> >> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com>
> >> >> wrote:
> >> >> >> > >
> >> >> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with
> pull
> >> >> >> request
> >> >> >> > > > included.
> >> >> >> > > >
> >> >> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <shazron@gmail.com
> >
> >> >> >>wrote:
> >> >> >> > > >
> >> >> >> > > > > Sorry I should have looked into the File API code first
> (no
> >> >> >> > JavaScript
> >> >> >> > > > > changes, that would not work).
> >> >> >> > > > >
> >> >> >> > > > > Essentially I need to "override" this line from my plugin:
> >> >> >> > > > >
> >> >> >> > > >
> >> >> >> > > https://github.com/apache/cordova-plugin-file/blob/
> >> >> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
> >> >> >> > CDVAssetLibraryFilesystem.m#L74
> >> >> >> > > > > (plus the CDVLocalFileSystem equivalent).
> >> >> >> > > > >
> >> >> >> > > > > Since Obj-C categories can't really "override" methods
> >> >>(behavior
> >> >> >> > > > > undefined), and I don't want to do some runtime swap
> >> >> >>implementation
> >> >> >> > > > voodoo,
> >> >> >> > > > > I would replace the line above with something like:
> >> >> >> > > > >
> >> >> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
> >> >> >> > > > > "assets-library:/%@",fullPath];
> >> >> >> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)])
> {
> >> >>//
> >> >> >> some
> >> >> >> > > > > unique selector name perhaps
> >> >> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this
> >> >> >> > > > > code
> >> >> >>won't
> >> >> >> > > > > compile, pseudo-code for now. Will call my category method
> >> >> >>defined
> >> >> >> in
> >> >> >> > > my
> >> >> >> > > > > plugin for CDVAssetLibraryFileSystem
> >> >> >> > > > > }
> >> >> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
> >> >> >> > > > >
> >> >> >> > > > > Backwards compatible.
> >> >> >> > > > >
> >> >> >> > > > >
> >> >> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <
> shazron@gmail.com>
> >> >> >> wrote:
> >> >> >> > > > >
> >> >> >> > > > >> Local Web Server Checklist:
> >> >> >> > > > >> 1. We have random port usage
> >> >> >> > > > >> 2. We have the token/cookie check
> >> >> >> > > > >> 3. We have the localhost check
> >> >> >> > > > >> 4. The app is now installed under
> >> >>http://localhost:RANDOM_PORT
> >> >> >> /www/
> >> >> >> > > > >>
> >> >> >> > > > >> It'll be easy (relatively) to add support for:
> >> >> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
> >> >> >> > > > >> http://localhost:RANDOM_PORT/file-system/
> >> >> >> > > > >>
> >> >> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm
> >> >>thinking
> >> >> >>of
> >> >> >> > some
> >> >> >> > > > >> runtime 'magic' in the local web server where it detects
> >> >> >> > > > >> the
> >> >> >>File
> >> >> >> > > > plugin,
> >> >> >> > > > >> and change the implementation of FileEntry.toURL() (or
> >> >>through
> >> >> >> > > injecting
> >> >> >> > > > >> JavaScript, probably easier).
> >> >> >> > > > >>
> >> >> >> > > > >>
> >> >> >> > > > >> 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
> >> >><sh...@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
>
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
No dice in iOS 8.2b2 that was released today:
https://issues.apache.org/jira/browse/CB-7090?focusedCommentId=14241546&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14241546
On Thu, Nov 20, 2014 at 1:37 PM, Shazron <sh...@gmail.com> wrote:
> I updated https://issues.apache.org/jira/browse/CB-8032 with my revised
> approach. I'd like to move on with this as soon as possible.
>
> Let's continue the discussion there.
>
> On Wed, Nov 19, 2014 at 1:14 PM, Homer, Tony <to...@intel.com> wrote:
>>
>> Ugh. Thanks for the additional information, Shazron.
>>
>> I had previously proposed adding a hook (by which I meant a delegate
>> method) to CDVPluginResult (that would be called from -
>> (CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
>> message:(id)theMessage) so that LocalWebServer could (blindly) detect and
>> transform urls.
>>
>> It seems like it would help with this case, but not be generally useful
>> for anything else…
>>
>> Tony
>>
>> On 11/19/14, 3:23 PM, "Shazron" <sh...@gmail.com> wrote:
>>
>> >Ideally a general solution like you proposed should work, but I forgot to
>> >mention that in this case, since we are talking about WKWebView, we can't
>> >use NSURLProtocol since it is not supported in that framework [1][2]
>> >
>> >The only other general way I can see is to require explicit support in
>> >plugins, they may have to call something in the
>> >commandDelegate/viewController to transform a url, that can be set by
>> >another plugin, in this case LocalWebServer (my revised proposal was a
>> >'push' this is a 'pull').
>> >
>> >
>> >[1] https://issues.apache.org/jira/browse/CB-7049
>> >[2] http://www.openradar.me/18492325
>> >
>> >On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com>
>> >wrote:
>> >
>> >> If we are just talking about CB-8032, then I can see that this approach
>> >>is
>> >> cleaner for the file plugin.
>> >>
>> >> Regarding local web server plugin in general - what about other plugins
>> >> such as camera?
>> >> Doesn¹t there need to be a general solution that will provide
>> >> compatibility between local web server plugin and any plugin that
>> >>returns
>> >> a file protocol URL?
>> >>
>> >> Tony
>> >>
>> >> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
>> >>
>> >> >I commented on Ian's comment on CB-8032:
>> >> >
>> >>
>>
>> >> >>https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p
>> >>a
>> >>
>>
>> >>> >>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
>> >>>en
>> >> >t-14216403
>> >> >
>> >> >My goal was to have a loose coupling of this functionality (CDVFile
>> >>need
>> >> >not know about LocalWebServer at all) -- and Ian's comment of this
>> >>change
>> >> >is that would impact all CDVFileSystem instances makes this not an
>> >>ideal
>> >> >solution, what if you have two Cordova WebView instances, etc.
>> >> >
>> >> >My revised proposal requires CDVFileSystem to have a delegate that can
>> >>be
>> >> >set. Any class can set it to override the nativeURL behaviour, and
>> >> >CDVFileSystem will call this method in the delegate if available. It
>> >> >achieves the same goal without the potentially undefined behaviour of
>> >>an
>> >> >Obj-C Category.
>> >> >
>> >> >The LocalWebServer gets the currently installed File plugin,
>> >> > enumerates
>> >> >all
>> >> >available filesystems, and sets this delegate on each, to its own
>> >> >implementation.
>> >> >
>> >> >Tony - I think this is approach is cleaner, and is more maintainable.
>> >> >
>> >> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <ic...@chromium.org>
>> >> >wrote:
>> >> >
>> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com>
>> >>wrote:
>> >> >>
>> >> >> > Shaz's solution has less impact and seems more elegant.
>> >> >> >
>> >> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>> >> >> >
>> >> >> > If no-one ( generically ) has provided the nativeFullPath method,
>> >>then
>> >> >> use
>> >> >> > it as is, otherwise call it.
>> >> >> > No need for any (direct) dependency between File + LocalServer.
>> >> >> >
>> >> >>
>> >> >> My first instinct, looking at the code, was that it was wrong,
>> >>exactly
>> >> >> because there *is* a dependency. You don't normally add code to a
>> >>base
>> >> >> class to change its behaviour when there is a category defined on
>> >> >> it.
>> >> >> Normally that goes the other way: when you add a category to a base
>> >> >>class,
>> >> >> all of the code that's relevant to that category is *in the
>> >>category*,
>> >> >>and
>> >> >> the base class needs to know nothing at all about it, including its
>> >> >> existence.
>> >> >>
>> >> >> As I said in the PR, it may be that this really is the cleanest and
>> >>best
>> >> >> way to go forward with this; I just wanted to have this discussion
>> >>and
>> >> >> figure it out with the community before committing to any
>> >> >> hard-to-change-later technical debt. It does become an API surface,
>> >>and
>> >> >>we
>> >> >> will have to maintain whatever we adopt.
>> >> >>
>> >> >> Ian
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > @purplecabbage
>> >> >> > risingj.com
>> >> >> >
>> >> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
>> >><agrieve@chromium.org
>> >> >
>> >> >> > wrote:
>> >> >> >
>> >> >> > > Having the localserver plugin add behaviour to file plugin feels
>> >> >>like
>> >> >> the
>> >> >> > > dependency is in the wrong direction to me.
>> >> >> > >
>> >> >> > > How about having CDVFile.m do something like:
>> >> >> > >
>> >> >> > > CDVPlugin* p = [commandDelegate
>> >>getCommandInstance:@"LocalServer"];
>> >> >> > > if (p != nil) {
>> >> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
>> >> >>declaration
>> >> >> to
>> >> >> > > make this not complain about unrecognized selector
>> >> >> > > }
>> >> >> > >
>> >> >> > > Would probably also need an "untransformURL" to go the other
>> >> >>direction
>> >> >> as
>> >> >> > > well.
>> >> >> > >
>> >> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com>
>> >> wrote:
>> >> >> > >
>> >> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
>> >> >> request
>> >> >> > > > included.
>> >> >> > > >
>> >> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com>
>> >> >>wrote:
>> >> >> > > >
>> >> >> > > > > Sorry I should have looked into the File API code first (no
>> >> >> > JavaScript
>> >> >> > > > > changes, that would not work).
>> >> >> > > > >
>> >> >> > > > > Essentially I need to "override" this line from my plugin:
>> >> >> > > > >
>> >> >> > > >
>> >> >> > > https://github.com/apache/cordova-plugin-file/blob/
>> >> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
>> >> >> > CDVAssetLibraryFilesystem.m#L74
>> >> >> > > > > (plus the CDVLocalFileSystem equivalent).
>> >> >> > > > >
>> >> >> > > > > Since Obj-C categories can't really "override" methods
>> >>(behavior
>> >> >> > > > > undefined), and I don't want to do some runtime swap
>> >> >>implementation
>> >> >> > > > voodoo,
>> >> >> > > > > I would replace the line above with something like:
>> >> >> > > > >
>> >> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
>> >> >> > > > > "assets-library:/%@",fullPath];
>> >> >> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>> >>//
>> >> >> some
>> >> >> > > > > unique selector name perhaps
>> >> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this
>> >> >> > > > > code
>> >> >>won't
>> >> >> > > > > compile, pseudo-code for now. Will call my category method
>> >> >>defined
>> >> >> in
>> >> >> > > my
>> >> >> > > > > plugin for CDVAssetLibraryFileSystem
>> >> >> > > > > }
>> >> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
>> >> >> > > > >
>> >> >> > > > > Backwards compatible.
>> >> >> > > > >
>> >> >> > > > >
>> >> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com>
>> >> >> wrote:
>> >> >> > > > >
>> >> >> > > > >> Local Web Server Checklist:
>> >> >> > > > >> 1. We have random port usage
>> >> >> > > > >> 2. We have the token/cookie check
>> >> >> > > > >> 3. We have the localhost check
>> >> >> > > > >> 4. The app is now installed under
>> >>http://localhost:RANDOM_PORT
>> >> >> /www/
>> >> >> > > > >>
>> >> >> > > > >> It'll be easy (relatively) to add support for:
>> >> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
>> >> >> > > > >> http://localhost:RANDOM_PORT/file-system/
>> >> >> > > > >>
>> >> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm
>> >>thinking
>> >> >>of
>> >> >> > some
>> >> >> > > > >> runtime 'magic' in the local web server where it detects
>> >> >> > > > >> the
>> >> >>File
>> >> >> > > > plugin,
>> >> >> > > > >> and change the implementation of FileEntry.toURL() (or
>> >>through
>> >> >> > > injecting
>> >> >> > > > >> JavaScript, probably easier).
>> >> >> > > > >>
>> >> >> > > > >>
>> >> >> > > > >> 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
>> >><sh...@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" <sh...@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
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
I updated https://issues.apache.org/jira/browse/CB-8032 with my revised
approach. I'd like to move on with this as soon as possible.
Let's continue the discussion there.
On Wed, Nov 19, 2014 at 1:14 PM, Homer, Tony <to...@intel.com> wrote:
> Ugh. Thanks for the additional information, Shazron.
>
> I had previously proposed adding a hook (by which I meant a delegate
> method) to CDVPluginResult (that would be called from -
> (CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
> message:(id)theMessage) so that LocalWebServer could (blindly) detect and
> transform urls.
>
> It seems like it would help with this case, but not be generally useful
> for anything else…
>
> Tony
>
> On 11/19/14, 3:23 PM, "Shazron" <sh...@gmail.com> wrote:
>
> >Ideally a general solution like you proposed should work, but I forgot to
> >mention that in this case, since we are talking about WKWebView, we can't
> >use NSURLProtocol since it is not supported in that framework [1][2]
> >
> >The only other general way I can see is to require explicit support in
> >plugins, they may have to call something in the
> >commandDelegate/viewController to transform a url, that can be set by
> >another plugin, in this case LocalWebServer (my revised proposal was a
> >'push' this is a 'pull').
> >
> >
> >[1] https://issues.apache.org/jira/browse/CB-7049
> >[2] http://www.openradar.me/18492325
> >
> >On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com>
> >wrote:
> >
> >> If we are just talking about CB-8032, then I can see that this approach
> >>is
> >> cleaner for the file plugin.
> >>
> >> Regarding local web server plugin in general - what about other plugins
> >> such as camera?
> >> Doesn¹t there need to be a general solution that will provide
> >> compatibility between local web server plugin and any plugin that
> >>returns
> >> a file protocol URL?
> >>
> >> Tony
> >>
> >> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
> >>
> >> >I commented on Ian's comment on CB-8032:
> >> >
> >>
> >>
> https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p
> >>a
> >>
> >>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
> >>>en
> >> >t-14216403
> >> >
> >> >My goal was to have a loose coupling of this functionality (CDVFile
> >>need
> >> >not know about LocalWebServer at all) -- and Ian's comment of this
> >>change
> >> >is that would impact all CDVFileSystem instances makes this not an
> >>ideal
> >> >solution, what if you have two Cordova WebView instances, etc.
> >> >
> >> >My revised proposal requires CDVFileSystem to have a delegate that can
> >>be
> >> >set. Any class can set it to override the nativeURL behaviour, and
> >> >CDVFileSystem will call this method in the delegate if available. It
> >> >achieves the same goal without the potentially undefined behaviour of
> >>an
> >> >Obj-C Category.
> >> >
> >> >The LocalWebServer gets the currently installed File plugin, enumerates
> >> >all
> >> >available filesystems, and sets this delegate on each, to its own
> >> >implementation.
> >> >
> >> >Tony - I think this is approach is cleaner, and is more maintainable.
> >> >
> >> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <ic...@chromium.org>
> >> >wrote:
> >> >
> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com>
> >>wrote:
> >> >>
> >> >> > Shaz's solution has less impact and seems more elegant.
> >> >> >
> >> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
> >> >> >
> >> >> > If no-one ( generically ) has provided the nativeFullPath method,
> >>then
> >> >> use
> >> >> > it as is, otherwise call it.
> >> >> > No need for any (direct) dependency between File + LocalServer.
> >> >> >
> >> >>
> >> >> My first instinct, looking at the code, was that it was wrong,
> >>exactly
> >> >> because there *is* a dependency. You don't normally add code to a
> >>base
> >> >> class to change its behaviour when there is a category defined on it.
> >> >> Normally that goes the other way: when you add a category to a base
> >> >>class,
> >> >> all of the code that's relevant to that category is *in the
> >>category*,
> >> >>and
> >> >> the base class needs to know nothing at all about it, including its
> >> >> existence.
> >> >>
> >> >> As I said in the PR, it may be that this really is the cleanest and
> >>best
> >> >> way to go forward with this; I just wanted to have this discussion
> >>and
> >> >> figure it out with the community before committing to any
> >> >> hard-to-change-later technical debt. It does become an API surface,
> >>and
> >> >>we
> >> >> will have to maintain whatever we adopt.
> >> >>
> >> >> Ian
> >> >>
> >> >>
> >> >> >
> >> >> > @purplecabbage
> >> >> > risingj.com
> >> >> >
> >> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
> >><agrieve@chromium.org
> >> >
> >> >> > wrote:
> >> >> >
> >> >> > > Having the localserver plugin add behaviour to file plugin feels
> >> >>like
> >> >> the
> >> >> > > dependency is in the wrong direction to me.
> >> >> > >
> >> >> > > How about having CDVFile.m do something like:
> >> >> > >
> >> >> > > CDVPlugin* p = [commandDelegate
> >>getCommandInstance:@"LocalServer"];
> >> >> > > if (p != nil) {
> >> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
> >> >>declaration
> >> >> to
> >> >> > > make this not complain about unrecognized selector
> >> >> > > }
> >> >> > >
> >> >> > > Would probably also need an "untransformURL" to go the other
> >> >>direction
> >> >> as
> >> >> > > well.
> >> >> > >
> >> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com>
> >> wrote:
> >> >> > >
> >> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
> >> >> request
> >> >> > > > included.
> >> >> > > >
> >> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com>
> >> >>wrote:
> >> >> > > >
> >> >> > > > > Sorry I should have looked into the File API code first (no
> >> >> > JavaScript
> >> >> > > > > changes, that would not work).
> >> >> > > > >
> >> >> > > > > Essentially I need to "override" this line from my plugin:
> >> >> > > > >
> >> >> > > >
> >> >> > > https://github.com/apache/cordova-plugin-file/blob/
> >> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
> >> >> > CDVAssetLibraryFilesystem.m#L74
> >> >> > > > > (plus the CDVLocalFileSystem equivalent).
> >> >> > > > >
> >> >> > > > > Since Obj-C categories can't really "override" methods
> >>(behavior
> >> >> > > > > undefined), and I don't want to do some runtime swap
> >> >>implementation
> >> >> > > > voodoo,
> >> >> > > > > I would replace the line above with something like:
> >> >> > > > >
> >> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
> >> >> > > > > "assets-library:/%@",fullPath];
> >> >> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) {
> >>//
> >> >> some
> >> >> > > > > unique selector name perhaps
> >> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this code
> >> >>won't
> >> >> > > > > compile, pseudo-code for now. Will call my category method
> >> >>defined
> >> >> in
> >> >> > > my
> >> >> > > > > plugin for CDVAssetLibraryFileSystem
> >> >> > > > > }
> >> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
> >> >> > > > >
> >> >> > > > > Backwards compatible.
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com>
> >> >> wrote:
> >> >> > > > >
> >> >> > > > >> Local Web Server Checklist:
> >> >> > > > >> 1. We have random port usage
> >> >> > > > >> 2. We have the token/cookie check
> >> >> > > > >> 3. We have the localhost check
> >> >> > > > >> 4. The app is now installed under
> >>http://localhost:RANDOM_PORT
> >> >> /www/
> >> >> > > > >>
> >> >> > > > >> It'll be easy (relatively) to add support for:
> >> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
> >> >> > > > >> http://localhost:RANDOM_PORT/file-system/
> >> >> > > > >>
> >> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm
> >>thinking
> >> >>of
> >> >> > some
> >> >> > > > >> runtime 'magic' in the local web server where it detects the
> >> >>File
> >> >> > > > plugin,
> >> >> > > > >> and change the implementation of FileEntry.toURL() (or
> >>through
> >> >> > > injecting
> >> >> > > > >> JavaScript, probably easier).
> >> >> > > > >>
> >> >> > > > >>
> >> >> > > > >> 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
> >><sh...@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" <sh...@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
> >>
> >>
>
>
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
Ugh. Thanks for the additional information, Shazron.
I had previously proposed adding a hook (by which I meant a delegate
method) to CDVPluginResult (that would be called from -
(CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
message:(id)theMessage) so that LocalWebServer could (blindly) detect and
transform urls.
It seems like it would help with this case, but not be generally useful
for anything else…
Tony
On 11/19/14, 3:23 PM, "Shazron" <sh...@gmail.com> wrote:
>Ideally a general solution like you proposed should work, but I forgot to
>mention that in this case, since we are talking about WKWebView, we can't
>use NSURLProtocol since it is not supported in that framework [1][2]
>
>The only other general way I can see is to require explicit support in
>plugins, they may have to call something in the
>commandDelegate/viewController to transform a url, that can be set by
>another plugin, in this case LocalWebServer (my revised proposal was a
>'push' this is a 'pull').
>
>
>[1] https://issues.apache.org/jira/browse/CB-7049
>[2] http://www.openradar.me/18492325
>
>On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com>
>wrote:
>
>> If we are just talking about CB-8032, then I can see that this approach
>>is
>> cleaner for the file plugin.
>>
>> Regarding local web server plugin in general - what about other plugins
>> such as camera?
>> Doesn¹t there need to be a general solution that will provide
>> compatibility between local web server plugin and any plugin that
>>returns
>> a file protocol URL?
>>
>> Tony
>>
>> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
>>
>> >I commented on Ian's comment on CB-8032:
>> >
>>
>>https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p
>>a
>>
>>>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
>>>en
>> >t-14216403
>> >
>> >My goal was to have a loose coupling of this functionality (CDVFile
>>need
>> >not know about LocalWebServer at all) -- and Ian's comment of this
>>change
>> >is that would impact all CDVFileSystem instances makes this not an
>>ideal
>> >solution, what if you have two Cordova WebView instances, etc.
>> >
>> >My revised proposal requires CDVFileSystem to have a delegate that can
>>be
>> >set. Any class can set it to override the nativeURL behaviour, and
>> >CDVFileSystem will call this method in the delegate if available. It
>> >achieves the same goal without the potentially undefined behaviour of
>>an
>> >Obj-C Category.
>> >
>> >The LocalWebServer gets the currently installed File plugin, enumerates
>> >all
>> >available filesystems, and sets this delegate on each, to its own
>> >implementation.
>> >
>> >Tony - I think this is approach is cleaner, and is more maintainable.
>> >
>> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <ic...@chromium.org>
>> >wrote:
>> >
>> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com>
>>wrote:
>> >>
>> >> > Shaz's solution has less impact and seems more elegant.
>> >> >
>> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>> >> >
>> >> > If no-one ( generically ) has provided the nativeFullPath method,
>>then
>> >> use
>> >> > it as is, otherwise call it.
>> >> > No need for any (direct) dependency between File + LocalServer.
>> >> >
>> >>
>> >> My first instinct, looking at the code, was that it was wrong,
>>exactly
>> >> because there *is* a dependency. You don't normally add code to a
>>base
>> >> class to change its behaviour when there is a category defined on it.
>> >> Normally that goes the other way: when you add a category to a base
>> >>class,
>> >> all of the code that's relevant to that category is *in the
>>category*,
>> >>and
>> >> the base class needs to know nothing at all about it, including its
>> >> existence.
>> >>
>> >> As I said in the PR, it may be that this really is the cleanest and
>>best
>> >> way to go forward with this; I just wanted to have this discussion
>>and
>> >> figure it out with the community before committing to any
>> >> hard-to-change-later technical debt. It does become an API surface,
>>and
>> >>we
>> >> will have to maintain whatever we adopt.
>> >>
>> >> Ian
>> >>
>> >>
>> >> >
>> >> > @purplecabbage
>> >> > risingj.com
>> >> >
>> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve
>><agrieve@chromium.org
>> >
>> >> > wrote:
>> >> >
>> >> > > Having the localserver plugin add behaviour to file plugin feels
>> >>like
>> >> the
>> >> > > dependency is in the wrong direction to me.
>> >> > >
>> >> > > How about having CDVFile.m do something like:
>> >> > >
>> >> > > CDVPlugin* p = [commandDelegate
>>getCommandInstance:@"LocalServer"];
>> >> > > if (p != nil) {
>> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
>> >>declaration
>> >> to
>> >> > > make this not complain about unrecognized selector
>> >> > > }
>> >> > >
>> >> > > Would probably also need an "untransformURL" to go the other
>> >>direction
>> >> as
>> >> > > well.
>> >> > >
>> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com>
>> wrote:
>> >> > >
>> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
>> >> request
>> >> > > > included.
>> >> > > >
>> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com>
>> >>wrote:
>> >> > > >
>> >> > > > > Sorry I should have looked into the File API code first (no
>> >> > JavaScript
>> >> > > > > changes, that would not work).
>> >> > > > >
>> >> > > > > Essentially I need to "override" this line from my plugin:
>> >> > > > >
>> >> > > >
>> >> > > https://github.com/apache/cordova-plugin-file/blob/
>> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
>> >> > CDVAssetLibraryFilesystem.m#L74
>> >> > > > > (plus the CDVLocalFileSystem equivalent).
>> >> > > > >
>> >> > > > > Since Obj-C categories can't really "override" methods
>>(behavior
>> >> > > > > undefined), and I don't want to do some runtime swap
>> >>implementation
>> >> > > > voodoo,
>> >> > > > > I would replace the line above with something like:
>> >> > > > >
>> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
>> >> > > > > "assets-library:/%@",fullPath];
>> >> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>>//
>> >> some
>> >> > > > > unique selector name perhaps
>> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this code
>> >>won't
>> >> > > > > compile, pseudo-code for now. Will call my category method
>> >>defined
>> >> in
>> >> > > my
>> >> > > > > plugin for CDVAssetLibraryFileSystem
>> >> > > > > }
>> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
>> >> > > > >
>> >> > > > > Backwards compatible.
>> >> > > > >
>> >> > > > >
>> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com>
>> >> wrote:
>> >> > > > >
>> >> > > > >> Local Web Server Checklist:
>> >> > > > >> 1. We have random port usage
>> >> > > > >> 2. We have the token/cookie check
>> >> > > > >> 3. We have the localhost check
>> >> > > > >> 4. The app is now installed under
>>http://localhost:RANDOM_PORT
>> >> /www/
>> >> > > > >>
>> >> > > > >> It'll be easy (relatively) to add support for:
>> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
>> >> > > > >> http://localhost:RANDOM_PORT/file-system/
>> >> > > > >>
>> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm
>>thinking
>> >>of
>> >> > some
>> >> > > > >> runtime 'magic' in the local web server where it detects the
>> >>File
>> >> > > > plugin,
>> >> > > > >> and change the implementation of FileEntry.toURL() (or
>>through
>> >> > > injecting
>> >> > > > >> JavaScript, probably easier).
>> >> > > > >>
>> >> > > > >>
>> >> > > > >> 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
>><sh...@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" <sh...@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
>>
>>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Ideally a general solution like you proposed should work, but I forgot to
mention that in this case, since we are talking about WKWebView, we can't
use NSURLProtocol since it is not supported in that framework [1][2]
The only other general way I can see is to require explicit support in
plugins, they may have to call something in the
commandDelegate/viewController to transform a url, that can be set by
another plugin, in this case LocalWebServer (my revised proposal was a
'push' this is a 'pull').
[1] https://issues.apache.org/jira/browse/CB-7049
[2] http://www.openradar.me/18492325
On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony <to...@intel.com> wrote:
> If we are just talking about CB-8032, then I can see that this approach is
> cleaner for the file plugin.
>
> Regarding local web server plugin in general - what about other plugins
> such as camera?
> Doesn¹t there need to be a general solution that will provide
> compatibility between local web server plugin and any plugin that returns
> a file protocol URL?
>
> Tony
>
> On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
>
> >I commented on Ian's comment on CB-8032:
> >
> https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&pa
> >ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
> >t-14216403
> >
> >My goal was to have a loose coupling of this functionality (CDVFile need
> >not know about LocalWebServer at all) -- and Ian's comment of this change
> >is that would impact all CDVFileSystem instances makes this not an ideal
> >solution, what if you have two Cordova WebView instances, etc.
> >
> >My revised proposal requires CDVFileSystem to have a delegate that can be
> >set. Any class can set it to override the nativeURL behaviour, and
> >CDVFileSystem will call this method in the delegate if available. It
> >achieves the same goal without the potentially undefined behaviour of an
> >Obj-C Category.
> >
> >The LocalWebServer gets the currently installed File plugin, enumerates
> >all
> >available filesystems, and sets this delegate on each, to its own
> >implementation.
> >
> >Tony - I think this is approach is cleaner, and is more maintainable.
> >
> >On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <ic...@chromium.org>
> >wrote:
> >
> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com> wrote:
> >>
> >> > Shaz's solution has less impact and seems more elegant.
> >> >
> >> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
> >> >
> >> > If no-one ( generically ) has provided the nativeFullPath method, then
> >> use
> >> > it as is, otherwise call it.
> >> > No need for any (direct) dependency between File + LocalServer.
> >> >
> >>
> >> My first instinct, looking at the code, was that it was wrong, exactly
> >> because there *is* a dependency. You don't normally add code to a base
> >> class to change its behaviour when there is a category defined on it.
> >> Normally that goes the other way: when you add a category to a base
> >>class,
> >> all of the code that's relevant to that category is *in the category*,
> >>and
> >> the base class needs to know nothing at all about it, including its
> >> existence.
> >>
> >> As I said in the PR, it may be that this really is the cleanest and best
> >> way to go forward with this; I just wanted to have this discussion and
> >> figure it out with the community before committing to any
> >> hard-to-change-later technical debt. It does become an API surface, and
> >>we
> >> will have to maintain whatever we adopt.
> >>
> >> Ian
> >>
> >>
> >> >
> >> > @purplecabbage
> >> > risingj.com
> >> >
> >> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve <agrieve@chromium.org
> >
> >> > wrote:
> >> >
> >> > > Having the localserver plugin add behaviour to file plugin feels
> >>like
> >> the
> >> > > dependency is in the wrong direction to me.
> >> > >
> >> > > How about having CDVFile.m do something like:
> >> > >
> >> > > CDVPlugin* p = [commandDelegate getCommandInstance:@"LocalServer"];
> >> > > if (p != nil) {
> >> > > nativeURL = [p transformURL:nativeURL]; // do some local
> >>declaration
> >> to
> >> > > make this not complain about unrecognized selector
> >> > > }
> >> > >
> >> > > Would probably also need an "untransformURL" to go the other
> >>direction
> >> as
> >> > > well.
> >> > >
> >> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com>
> wrote:
> >> > >
> >> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
> >> request
> >> > > > included.
> >> > > >
> >> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com>
> >>wrote:
> >> > > >
> >> > > > > Sorry I should have looked into the File API code first (no
> >> > JavaScript
> >> > > > > changes, that would not work).
> >> > > > >
> >> > > > > Essentially I need to "override" this line from my plugin:
> >> > > > >
> >> > > >
> >> > > https://github.com/apache/cordova-plugin-file/blob/
> >> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
> >> > CDVAssetLibraryFilesystem.m#L74
> >> > > > > (plus the CDVLocalFileSystem equivalent).
> >> > > > >
> >> > > > > Since Obj-C categories can't really "override" methods (behavior
> >> > > > > undefined), and I don't want to do some runtime swap
> >>implementation
> >> > > > voodoo,
> >> > > > > I would replace the line above with something like:
> >> > > > >
> >> > > > > NSString* nativeURL = [NSString stringWithFormat:@
> >> > > > > "assets-library:/%@",fullPath];
> >> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) { //
> >> some
> >> > > > > unique selector name perhaps
> >> > > > > nativeURL = [self nativeFullPath:fullPath]; // this code
> >>won't
> >> > > > > compile, pseudo-code for now. Will call my category method
> >>defined
> >> in
> >> > > my
> >> > > > > plugin for CDVAssetLibraryFileSystem
> >> > > > > }
> >> > > > > dirEntry[@"nativeURL"] = nativeURL;
> >> > > > >
> >> > > > > Backwards compatible.
> >> > > > >
> >> > > > >
> >> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com>
> >> wrote:
> >> > > > >
> >> > > > >> Local Web Server Checklist:
> >> > > > >> 1. We have random port usage
> >> > > > >> 2. We have the token/cookie check
> >> > > > >> 3. We have the localhost check
> >> > > > >> 4. The app is now installed under http://localhost:RANDOM_PORT
> >> /www/
> >> > > > >>
> >> > > > >> It'll be easy (relatively) to add support for:
> >> > > > >> http://localhost:RANDOM_PORT/asset-library/
> >> > > > >> http://localhost:RANDOM_PORT/file-system/
> >> > > > >>
> >> > > > >> The only issue now is changing FileEntry.toURL(). I'm thinking
> >>of
> >> > some
> >> > > > >> runtime 'magic' in the local web server where it detects the
> >>File
> >> > > > plugin,
> >> > > > >> and change the implementation of FileEntry.toURL() (or through
> >> > > injecting
> >> > > > >> JavaScript, probably easier).
> >> > > > >>
> >> > > > >>
> >> > > > >> 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 <sh...@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" <sh...@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
>
>
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
If we are just talking about CB-8032, then I can see that this approach is
cleaner for the file plugin.
Regarding local web server plugin in general - what about other plugins
such as camera?
Doesn¹t there need to be a general solution that will provide
compatibility between local web server plugin and any plugin that returns
a file protocol URL?
Tony
On 11/19/14, 12:19 PM, "Shazron" <sh...@gmail.com> wrote:
>I commented on Ian's comment on CB-8032:
>https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&pa
>ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
>t-14216403
>
>My goal was to have a loose coupling of this functionality (CDVFile need
>not know about LocalWebServer at all) -- and Ian's comment of this change
>is that would impact all CDVFileSystem instances makes this not an ideal
>solution, what if you have two Cordova WebView instances, etc.
>
>My revised proposal requires CDVFileSystem to have a delegate that can be
>set. Any class can set it to override the nativeURL behaviour, and
>CDVFileSystem will call this method in the delegate if available. It
>achieves the same goal without the potentially undefined behaviour of an
>Obj-C Category.
>
>The LocalWebServer gets the currently installed File plugin, enumerates
>all
>available filesystems, and sets this delegate on each, to its own
>implementation.
>
>Tony - I think this is approach is cleaner, and is more maintainable.
>
>On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <ic...@chromium.org>
>wrote:
>
>> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com> wrote:
>>
>> > Shaz's solution has less impact and seems more elegant.
>> >
>> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>> >
>> > If no-one ( generically ) has provided the nativeFullPath method, then
>> use
>> > it as is, otherwise call it.
>> > No need for any (direct) dependency between File + LocalServer.
>> >
>>
>> My first instinct, looking at the code, was that it was wrong, exactly
>> because there *is* a dependency. You don't normally add code to a base
>> class to change its behaviour when there is a category defined on it.
>> Normally that goes the other way: when you add a category to a base
>>class,
>> all of the code that's relevant to that category is *in the category*,
>>and
>> the base class needs to know nothing at all about it, including its
>> existence.
>>
>> As I said in the PR, it may be that this really is the cleanest and best
>> way to go forward with this; I just wanted to have this discussion and
>> figure it out with the community before committing to any
>> hard-to-change-later technical debt. It does become an API surface, and
>>we
>> will have to maintain whatever we adopt.
>>
>> Ian
>>
>>
>> >
>> > @purplecabbage
>> > risingj.com
>> >
>> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve <ag...@chromium.org>
>> > wrote:
>> >
>> > > Having the localserver plugin add behaviour to file plugin feels
>>like
>> the
>> > > dependency is in the wrong direction to me.
>> > >
>> > > How about having CDVFile.m do something like:
>> > >
>> > > CDVPlugin* p = [commandDelegate getCommandInstance:@"LocalServer"];
>> > > if (p != nil) {
>> > > nativeURL = [p transformURL:nativeURL]; // do some local
>>declaration
>> to
>> > > make this not complain about unrecognized selector
>> > > }
>> > >
>> > > Would probably also need an "untransformURL" to go the other
>>direction
>> as
>> > > well.
>> > >
>> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com> wrote:
>> > >
>> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
>> request
>> > > > included.
>> > > >
>> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com>
>>wrote:
>> > > >
>> > > > > Sorry I should have looked into the File API code first (no
>> > JavaScript
>> > > > > changes, that would not work).
>> > > > >
>> > > > > Essentially I need to "override" this line from my plugin:
>> > > > >
>> > > >
>> > > https://github.com/apache/cordova-plugin-file/blob/
>> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
>> > CDVAssetLibraryFilesystem.m#L74
>> > > > > (plus the CDVLocalFileSystem equivalent).
>> > > > >
>> > > > > Since Obj-C categories can't really "override" methods (behavior
>> > > > > undefined), and I don't want to do some runtime swap
>>implementation
>> > > > voodoo,
>> > > > > I would replace the line above with something like:
>> > > > >
>> > > > > NSString* nativeURL = [NSString stringWithFormat:@
>> > > > > "assets-library:/%@",fullPath];
>> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) { //
>> some
>> > > > > unique selector name perhaps
>> > > > > nativeURL = [self nativeFullPath:fullPath]; // this code
>>won't
>> > > > > compile, pseudo-code for now. Will call my category method
>>defined
>> in
>> > > my
>> > > > > plugin for CDVAssetLibraryFileSystem
>> > > > > }
>> > > > > dirEntry[@"nativeURL"] = nativeURL;
>> > > > >
>> > > > > Backwards compatible.
>> > > > >
>> > > > >
>> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com>
>> wrote:
>> > > > >
>> > > > >> Local Web Server Checklist:
>> > > > >> 1. We have random port usage
>> > > > >> 2. We have the token/cookie check
>> > > > >> 3. We have the localhost check
>> > > > >> 4. The app is now installed under http://localhost:RANDOM_PORT
>> /www/
>> > > > >>
>> > > > >> It'll be easy (relatively) to add support for:
>> > > > >> http://localhost:RANDOM_PORT/asset-library/
>> > > > >> http://localhost:RANDOM_PORT/file-system/
>> > > > >>
>> > > > >> The only issue now is changing FileEntry.toURL(). I'm thinking
>>of
>> > some
>> > > > >> runtime 'magic' in the local web server where it detects the
>>File
>> > > > plugin,
>> > > > >> and change the implementation of FileEntry.toURL() (or through
>> > > injecting
>> > > > >> JavaScript, probably easier).
>> > > > >>
>> > > > >>
>> > > > >> 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 <sh...@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" <sh...@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
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
Since the last time I commented on this thread, I came across something
new (to me) that might work.
How about adding a custom NSURLProtocol to the LocalWebServer plugin and
setting it on the ?
This would allow the WebServer to intercept and redirect problematic
requests.
I just fixed a WebView caching bug in an app by adding a custom protocol.
In that case, I needed to intercept both the request and the response.
For this case we would
(1) intercept each request
(2) check if it matched a pattern
(3) if it matched the pattern, effectively redirect the request to the
local web server
This approach might require that a hook be added so that the custom
NSURLProtocol can be set at the right time, will have to check that.
I could put together a pull request to demonstrate, if it sounds worth
considering?
Tony
On 11/19/14, 9:20 AM, "Ian Clelland" <ic...@chromium.org> wrote:
>On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com> wrote:
>
>> Shaz's solution has less impact and seems more elegant.
>>
>> // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>>
>> If no-one ( generically ) has provided the nativeFullPath method, then
>>use
>> it as is, otherwise call it.
>> No need for any (direct) dependency between File + LocalServer.
>>
>
>My first instinct, looking at the code, was that it was wrong, exactly
>because there *is* a dependency. You don't normally add code to a base
>class to change its behaviour when there is a category defined on it.
>Normally that goes the other way: when you add a category to a base class,
>all of the code that's relevant to that category is *in the category*, and
>the base class needs to know nothing at all about it, including its
>existence.
>
>As I said in the PR, it may be that this really is the cleanest and best
>way to go forward with this; I just wanted to have this discussion and
>figure it out with the community before committing to any
>hard-to-change-later technical debt. It does become an API surface, and we
>will have to maintain whatever we adopt.
>
>Ian
>
>
>>
>> @purplecabbage
>> risingj.com
>>
>> On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>
>> > Having the localserver plugin add behaviour to file plugin feels like
>>the
>> > dependency is in the wrong direction to me.
>> >
>> > How about having CDVFile.m do something like:
>> >
>> > CDVPlugin* p = [commandDelegate getCommandInstance:@"LocalServer"];
>> > if (p != nil) {
>> > nativeURL = [p transformURL:nativeURL]; // do some local
>>declaration to
>> > make this not complain about unrecognized selector
>> > }
>> >
>> > Would probably also need an "untransformURL" to go the other
>>direction as
>> > well.
>> >
>> > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com> wrote:
>> >
>> > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
>>request
>> > > included.
>> > >
>> > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com> wrote:
>> > >
>> > > > Sorry I should have looked into the File API code first (no
>> JavaScript
>> > > > changes, that would not work).
>> > > >
>> > > > Essentially I need to "override" this line from my plugin:
>> > > >
>> > >
>> > https://github.com/apache/cordova-plugin-file/blob/
>> 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
>> CDVAssetLibraryFilesystem.m#L74
>> > > > (plus the CDVLocalFileSystem equivalent).
>> > > >
>> > > > Since Obj-C categories can't really "override" methods (behavior
>> > > > undefined), and I don't want to do some runtime swap
>>implementation
>> > > voodoo,
>> > > > I would replace the line above with something like:
>> > > >
>> > > > NSString* nativeURL = [NSString stringWithFormat:@
>> > > > "assets-library:/%@",fullPath];
>> > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) { //
>>some
>> > > > unique selector name perhaps
>> > > > nativeURL = [self nativeFullPath:fullPath]; // this code
>>won't
>> > > > compile, pseudo-code for now. Will call my category method
>>defined in
>> > my
>> > > > plugin for CDVAssetLibraryFileSystem
>> > > > }
>> > > > dirEntry[@"nativeURL"] = nativeURL;
>> > > >
>> > > > Backwards compatible.
>> > > >
>> > > >
>> > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com>
>>wrote:
>> > > >
>> > > >> Local Web Server Checklist:
>> > > >> 1. We have random port usage
>> > > >> 2. We have the token/cookie check
>> > > >> 3. We have the localhost check
>> > > >> 4. The app is now installed under
>>http://localhost:RANDOM_PORT/www/
>> > > >>
>> > > >> It'll be easy (relatively) to add support for:
>> > > >> http://localhost:RANDOM_PORT/asset-library/
>> > > >> http://localhost:RANDOM_PORT/file-system/
>> > > >>
>> > > >> The only issue now is changing FileEntry.toURL(). I'm thinking of
>> some
>> > > >> runtime 'magic' in the local web server where it detects the File
>> > > plugin,
>> > > >> and change the implementation of FileEntry.toURL() (or through
>> > injecting
>> > > >> JavaScript, probably easier).
>> > > >>
>> > > >>
>> > > >> 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 <sh...@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" <sh...@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
Re: [iOS 8] WKWebView moving forward
Posted by Kerri Shotts <ke...@photokandy.com>.
Really Apple? Really? Hisssssssssss!
Never mind my fangs. I've just dealt with a little too much Apple silliness
as of late. (Grrrrrrrrrrrrrrrrrrrr.)
;-)
On Wednesday, November 19, 2014, Shazron <sh...@gmail.com> wrote:
> Also, cue *sad violin*: the Xcode 6.2 beta SDK (iOS 8.2) does *not* include
> the WKWebView loadFileURL:readAccessURL: method.
>
>
>
--
___________________________________
*Kerri Shotts*
photoKandy Studios, LLC
On the Web: http://www.photokandy.com/
*Social Media:*
Twitter: @photokandy, http://twitter.com/photokandy
App.net: @photokandy, https://alpha.app.net/photokandy
Google+: https://plus.google.com/110429856422449500918/posts
Facebook: https://www.facebook.com/photoKandy
Behance: https://www.behance.net/kerrishotts
Tumblr: http://photokandy.tumblr.com/
Github: https://github.com/kerrishotts
https://github.com/organizations/photokandyStudios
CoderWall: https://coderwall.com/kerrishotts
Stack Overflow:
http://stackoverflow.com/users/741043/kerri-shotts
*Apps on the Apple Store:*
Greek Interlinear Bible 1.3:
https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828
*Books:*
PhoneGap 3.x Mobile Application Development Hotshot:
http://www.photokandy.com/books/phonegap-3-x-hotshot/
PhoneGap 2.x Mobile Application Development Hotshot:
http://www.photokandy.com/books/phonegap-2-x-hotshot/
Instant PhoneGap Social Application Development:
http://www.photokandy.com/books/instant-social-app/
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Also, cue *sad violin*: the Xcode 6.2 beta SDK (iOS 8.2) does *not* include
the WKWebView loadFileURL:readAccessURL: method.
On Wed, Nov 19, 2014 at 9:19 AM, Shazron <sh...@gmail.com> wrote:
> I commented on Ian's comment on CB-8032:
> https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14216403
>
> My goal was to have a loose coupling of this functionality (CDVFile need
> not know about LocalWebServer at all) -- and Ian's comment of this change
> is that would impact all CDVFileSystem instances makes this not an ideal
> solution, what if you have two Cordova WebView instances, etc.
>
> My revised proposal requires CDVFileSystem to have a delegate that can be
> set. Any class can set it to override the nativeURL behaviour, and
> CDVFileSystem will call this method in the delegate if available. It
> achieves the same goal without the potentially undefined behaviour of an
> Obj-C Category.
>
> The LocalWebServer gets the currently installed File plugin, enumerates
> all available filesystems, and sets this delegate on each, to its own
> implementation.
>
> Tony - I think this is approach is cleaner, and is more maintainable.
>
> On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <ic...@chromium.org>
> wrote:
>
>> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com> wrote:
>>
>> > Shaz's solution has less impact and seems more elegant.
>> >
>> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>> >
>> > If no-one ( generically ) has provided the nativeFullPath method, then
>> use
>> > it as is, otherwise call it.
>> > No need for any (direct) dependency between File + LocalServer.
>> >
>>
>> My first instinct, looking at the code, was that it was wrong, exactly
>> because there *is* a dependency. You don't normally add code to a base
>> class to change its behaviour when there is a category defined on it.
>> Normally that goes the other way: when you add a category to a base class,
>> all of the code that's relevant to that category is *in the category*, and
>> the base class needs to know nothing at all about it, including its
>> existence.
>>
>> As I said in the PR, it may be that this really is the cleanest and best
>> way to go forward with this; I just wanted to have this discussion and
>> figure it out with the community before committing to any
>> hard-to-change-later technical debt. It does become an API surface, and we
>> will have to maintain whatever we adopt.
>>
>> Ian
>>
>>
>> >
>> > @purplecabbage
>> > risingj.com
>> >
>> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve <ag...@chromium.org>
>> > wrote:
>> >
>> > > Having the localserver plugin add behaviour to file plugin feels like
>> the
>> > > dependency is in the wrong direction to me.
>> > >
>> > > How about having CDVFile.m do something like:
>> > >
>> > > CDVPlugin* p = [commandDelegate getCommandInstance:@"LocalServer"];
>> > > if (p != nil) {
>> > > nativeURL = [p transformURL:nativeURL]; // do some local
>> declaration to
>> > > make this not complain about unrecognized selector
>> > > }
>> > >
>> > > Would probably also need an "untransformURL" to go the other
>> direction as
>> > > well.
>> > >
>> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com> wrote:
>> > >
>> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
>> request
>> > > > included.
>> > > >
>> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com> wrote:
>> > > >
>> > > > > Sorry I should have looked into the File API code first (no
>> > JavaScript
>> > > > > changes, that would not work).
>> > > > >
>> > > > > Essentially I need to "override" this line from my plugin:
>> > > > >
>> > > >
>> > > https://github.com/apache/cordova-plugin-file/blob/
>> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
>> > CDVAssetLibraryFilesystem.m#L74
>> > > > > (plus the CDVLocalFileSystem equivalent).
>> > > > >
>> > > > > Since Obj-C categories can't really "override" methods (behavior
>> > > > > undefined), and I don't want to do some runtime swap
>> implementation
>> > > > voodoo,
>> > > > > I would replace the line above with something like:
>> > > > >
>> > > > > NSString* nativeURL = [NSString stringWithFormat:@
>> > > > > "assets-library:/%@",fullPath];
>> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) { //
>> some
>> > > > > unique selector name perhaps
>> > > > > nativeURL = [self nativeFullPath:fullPath]; // this code
>> won't
>> > > > > compile, pseudo-code for now. Will call my category method
>> defined in
>> > > my
>> > > > > plugin for CDVAssetLibraryFileSystem
>> > > > > }
>> > > > > dirEntry[@"nativeURL"] = nativeURL;
>> > > > >
>> > > > > Backwards compatible.
>> > > > >
>> > > > >
>> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com>
>> wrote:
>> > > > >
>> > > > >> Local Web Server Checklist:
>> > > > >> 1. We have random port usage
>> > > > >> 2. We have the token/cookie check
>> > > > >> 3. We have the localhost check
>> > > > >> 4. The app is now installed under http://localhost:RANDOM_PORT
>> /www/
>> > > > >>
>> > > > >> It'll be easy (relatively) to add support for:
>> > > > >> http://localhost:RANDOM_PORT/asset-library/
>> > > > >> http://localhost:RANDOM_PORT/file-system/
>> > > > >>
>> > > > >> The only issue now is changing FileEntry.toURL(). I'm thinking of
>> > some
>> > > > >> runtime 'magic' in the local web server where it detects the File
>> > > > plugin,
>> > > > >> and change the implementation of FileEntry.toURL() (or through
>> > > injecting
>> > > > >> JavaScript, probably easier).
>> > > > >>
>> > > > >>
>> > > > >> 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 <sh...@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" <sh...@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)
>> > > > >>> > > >
>> > > > >>> > >
>> > > > >>> >
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
I commented on Ian's comment on CB-8032:
https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14216403
My goal was to have a loose coupling of this functionality (CDVFile need
not know about LocalWebServer at all) -- and Ian's comment of this change
is that would impact all CDVFileSystem instances makes this not an ideal
solution, what if you have two Cordova WebView instances, etc.
My revised proposal requires CDVFileSystem to have a delegate that can be
set. Any class can set it to override the nativeURL behaviour, and
CDVFileSystem will call this method in the delegate if available. It
achieves the same goal without the potentially undefined behaviour of an
Obj-C Category.
The LocalWebServer gets the currently installed File plugin, enumerates all
available filesystems, and sets this delegate on each, to its own
implementation.
Tony - I think this is approach is cleaner, and is more maintainable.
On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland <ic...@chromium.org>
wrote:
> On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com> wrote:
>
> > Shaz's solution has less impact and seems more elegant.
> >
> > // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
> >
> > If no-one ( generically ) has provided the nativeFullPath method, then
> use
> > it as is, otherwise call it.
> > No need for any (direct) dependency between File + LocalServer.
> >
>
> My first instinct, looking at the code, was that it was wrong, exactly
> because there *is* a dependency. You don't normally add code to a base
> class to change its behaviour when there is a category defined on it.
> Normally that goes the other way: when you add a category to a base class,
> all of the code that's relevant to that category is *in the category*, and
> the base class needs to know nothing at all about it, including its
> existence.
>
> As I said in the PR, it may be that this really is the cleanest and best
> way to go forward with this; I just wanted to have this discussion and
> figure it out with the community before committing to any
> hard-to-change-later technical debt. It does become an API surface, and we
> will have to maintain whatever we adopt.
>
> Ian
>
>
> >
> > @purplecabbage
> > risingj.com
> >
> > On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > Having the localserver plugin add behaviour to file plugin feels like
> the
> > > dependency is in the wrong direction to me.
> > >
> > > How about having CDVFile.m do something like:
> > >
> > > CDVPlugin* p = [commandDelegate getCommandInstance:@"LocalServer"];
> > > if (p != nil) {
> > > nativeURL = [p transformURL:nativeURL]; // do some local declaration
> to
> > > make this not complain about unrecognized selector
> > > }
> > >
> > > Would probably also need an "untransformURL" to go the other direction
> as
> > > well.
> > >
> > > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com> wrote:
> > >
> > > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull
> request
> > > > included.
> > > >
> > > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com> wrote:
> > > >
> > > > > Sorry I should have looked into the File API code first (no
> > JavaScript
> > > > > changes, that would not work).
> > > > >
> > > > > Essentially I need to "override" this line from my plugin:
> > > > >
> > > >
> > > https://github.com/apache/cordova-plugin-file/blob/
> > 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
> > CDVAssetLibraryFilesystem.m#L74
> > > > > (plus the CDVLocalFileSystem equivalent).
> > > > >
> > > > > Since Obj-C categories can't really "override" methods (behavior
> > > > > undefined), and I don't want to do some runtime swap implementation
> > > > voodoo,
> > > > > I would replace the line above with something like:
> > > > >
> > > > > NSString* nativeURL = [NSString stringWithFormat:@
> > > > > "assets-library:/%@",fullPath];
> > > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) { //
> some
> > > > > unique selector name perhaps
> > > > > nativeURL = [self nativeFullPath:fullPath]; // this code won't
> > > > > compile, pseudo-code for now. Will call my category method defined
> in
> > > my
> > > > > plugin for CDVAssetLibraryFileSystem
> > > > > }
> > > > > dirEntry[@"nativeURL"] = nativeURL;
> > > > >
> > > > > Backwards compatible.
> > > > >
> > > > >
> > > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com>
> wrote:
> > > > >
> > > > >> Local Web Server Checklist:
> > > > >> 1. We have random port usage
> > > > >> 2. We have the token/cookie check
> > > > >> 3. We have the localhost check
> > > > >> 4. The app is now installed under http://localhost:RANDOM_PORT
> /www/
> > > > >>
> > > > >> It'll be easy (relatively) to add support for:
> > > > >> http://localhost:RANDOM_PORT/asset-library/
> > > > >> http://localhost:RANDOM_PORT/file-system/
> > > > >>
> > > > >> The only issue now is changing FileEntry.toURL(). I'm thinking of
> > some
> > > > >> runtime 'magic' in the local web server where it detects the File
> > > > plugin,
> > > > >> and change the implementation of FileEntry.toURL() (or through
> > > injecting
> > > > >> JavaScript, probably easier).
> > > > >>
> > > > >>
> > > > >> 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 <sh...@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" <sh...@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)
> > > > >>> > > >
> > > > >>> > >
> > > > >>> >
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Ian Clelland <ic...@chromium.org>.
On Tue Nov 18 2014 at 2:00:34 PM Jesse <pu...@gmail.com> wrote:
> Shaz's solution has less impact and seems more elegant.
>
> // if ([self respondsToSelector:@selector(nativeFullPath:)]) {
>
> If no-one ( generically ) has provided the nativeFullPath method, then use
> it as is, otherwise call it.
> No need for any (direct) dependency between File + LocalServer.
>
My first instinct, looking at the code, was that it was wrong, exactly
because there *is* a dependency. You don't normally add code to a base
class to change its behaviour when there is a category defined on it.
Normally that goes the other way: when you add a category to a base class,
all of the code that's relevant to that category is *in the category*, and
the base class needs to know nothing at all about it, including its
existence.
As I said in the PR, it may be that this really is the cleanest and best
way to go forward with this; I just wanted to have this discussion and
figure it out with the community before committing to any
hard-to-change-later technical debt. It does become an API surface, and we
will have to maintain whatever we adopt.
Ian
>
> @purplecabbage
> risingj.com
>
> On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Having the localserver plugin add behaviour to file plugin feels like the
> > dependency is in the wrong direction to me.
> >
> > How about having CDVFile.m do something like:
> >
> > CDVPlugin* p = [commandDelegate getCommandInstance:@"LocalServer"];
> > if (p != nil) {
> > nativeURL = [p transformURL:nativeURL]; // do some local declaration to
> > make this not complain about unrecognized selector
> > }
> >
> > Would probably also need an "untransformURL" to go the other direction as
> > well.
> >
> > On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com> wrote:
> >
> > > Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
> > > included.
> > >
> > > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > > > Sorry I should have looked into the File API code first (no
> JavaScript
> > > > changes, that would not work).
> > > >
> > > > Essentially I need to "override" this line from my plugin:
> > > >
> > >
> > https://github.com/apache/cordova-plugin-file/blob/
> 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
> CDVAssetLibraryFilesystem.m#L74
> > > > (plus the CDVLocalFileSystem equivalent).
> > > >
> > > > Since Obj-C categories can't really "override" methods (behavior
> > > > undefined), and I don't want to do some runtime swap implementation
> > > voodoo,
> > > > I would replace the line above with something like:
> > > >
> > > > NSString* nativeURL = [NSString stringWithFormat:@
> > > > "assets-library:/%@",fullPath];
> > > > if ([self respondsToSelector:@selector(nativeFullPath:)]) { // some
> > > > unique selector name perhaps
> > > > nativeURL = [self nativeFullPath:fullPath]; // this code won't
> > > > compile, pseudo-code for now. Will call my category method defined in
> > my
> > > > plugin for CDVAssetLibraryFileSystem
> > > > }
> > > > dirEntry[@"nativeURL"] = nativeURL;
> > > >
> > > > Backwards compatible.
> > > >
> > > >
> > > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com> wrote:
> > > >
> > > >> Local Web Server Checklist:
> > > >> 1. We have random port usage
> > > >> 2. We have the token/cookie check
> > > >> 3. We have the localhost check
> > > >> 4. The app is now installed under http://localhost:RANDOM_PORT/www/
> > > >>
> > > >> It'll be easy (relatively) to add support for:
> > > >> http://localhost:RANDOM_PORT/asset-library/
> > > >> http://localhost:RANDOM_PORT/file-system/
> > > >>
> > > >> The only issue now is changing FileEntry.toURL(). I'm thinking of
> some
> > > >> runtime 'magic' in the local web server where it detects the File
> > > plugin,
> > > >> and change the implementation of FileEntry.toURL() (or through
> > injecting
> > > >> JavaScript, probably easier).
> > > >>
> > > >>
> > > >> 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 <sh...@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" <sh...@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)
> > > >>> > > >
> > > >>> > >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Jesse <pu...@gmail.com>.
Shaz's solution has less impact and seems more elegant.
// if ([self respondsToSelector:@selector(nativeFullPath:)]) {
If no-one ( generically ) has provided the nativeFullPath method, then use
it as is, otherwise call it.
No need for any (direct) dependency between File + LocalServer.
@purplecabbage
risingj.com
On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve <ag...@chromium.org>
wrote:
> Having the localserver plugin add behaviour to file plugin feels like the
> dependency is in the wrong direction to me.
>
> How about having CDVFile.m do something like:
>
> CDVPlugin* p = [commandDelegate getCommandInstance:@"LocalServer"];
> if (p != nil) {
> nativeURL = [p transformURL:nativeURL]; // do some local declaration to
> make this not complain about unrecognized selector
> }
>
> Would probably also need an "untransformURL" to go the other direction as
> well.
>
> On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com> wrote:
>
> > Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
> > included.
> >
> > On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > Sorry I should have looked into the File API code first (no JavaScript
> > > changes, that would not work).
> > >
> > > Essentially I need to "override" this line from my plugin:
> > >
> >
> https://github.com/apache/cordova-plugin-file/blob/82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/CDVAssetLibraryFilesystem.m#L74
> > > (plus the CDVLocalFileSystem equivalent).
> > >
> > > Since Obj-C categories can't really "override" methods (behavior
> > > undefined), and I don't want to do some runtime swap implementation
> > voodoo,
> > > I would replace the line above with something like:
> > >
> > > NSString* nativeURL = [NSString stringWithFormat:@
> > > "assets-library:/%@",fullPath];
> > > if ([self respondsToSelector:@selector(nativeFullPath:)]) { // some
> > > unique selector name perhaps
> > > nativeURL = [self nativeFullPath:fullPath]; // this code won't
> > > compile, pseudo-code for now. Will call my category method defined in
> my
> > > plugin for CDVAssetLibraryFileSystem
> > > }
> > > dirEntry[@"nativeURL"] = nativeURL;
> > >
> > > Backwards compatible.
> > >
> > >
> > > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > >> Local Web Server Checklist:
> > >> 1. We have random port usage
> > >> 2. We have the token/cookie check
> > >> 3. We have the localhost check
> > >> 4. The app is now installed under http://localhost:RANDOM_PORT/www/
> > >>
> > >> It'll be easy (relatively) to add support for:
> > >> http://localhost:RANDOM_PORT/asset-library/
> > >> http://localhost:RANDOM_PORT/file-system/
> > >>
> > >> The only issue now is changing FileEntry.toURL(). I'm thinking of some
> > >> runtime 'magic' in the local web server where it detects the File
> > plugin,
> > >> and change the implementation of FileEntry.toURL() (or through
> injecting
> > >> JavaScript, probably easier).
> > >>
> > >>
> > >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve <ag...@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 <sh...@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" <sh...@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)
> > >>> > > >
> > >>> > >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Andrew Grieve <ag...@chromium.org>.
Having the localserver plugin add behaviour to file plugin feels like the
dependency is in the wrong direction to me.
How about having CDVFile.m do something like:
CDVPlugin* p = [commandDelegate getCommandInstance:@"LocalServer"];
if (p != nil) {
nativeURL = [p transformURL:nativeURL]; // do some local declaration to
make this not complain about unrecognized selector
}
Would probably also need an "untransformURL" to go the other direction as
well.
On Tue, Nov 18, 2014 at 12:05 AM, Shazron <sh...@gmail.com> wrote:
> Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
> included.
>
> On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com> wrote:
>
> > Sorry I should have looked into the File API code first (no JavaScript
> > changes, that would not work).
> >
> > Essentially I need to "override" this line from my plugin:
> >
> https://github.com/apache/cordova-plugin-file/blob/82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/CDVAssetLibraryFilesystem.m#L74
> > (plus the CDVLocalFileSystem equivalent).
> >
> > Since Obj-C categories can't really "override" methods (behavior
> > undefined), and I don't want to do some runtime swap implementation
> voodoo,
> > I would replace the line above with something like:
> >
> > NSString* nativeURL = [NSString stringWithFormat:@
> > "assets-library:/%@",fullPath];
> > if ([self respondsToSelector:@selector(nativeFullPath:)]) { // some
> > unique selector name perhaps
> > nativeURL = [self nativeFullPath:fullPath]; // this code won't
> > compile, pseudo-code for now. Will call my category method defined in my
> > plugin for CDVAssetLibraryFileSystem
> > }
> > dirEntry[@"nativeURL"] = nativeURL;
> >
> > Backwards compatible.
> >
> >
> > On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com> wrote:
> >
> >> Local Web Server Checklist:
> >> 1. We have random port usage
> >> 2. We have the token/cookie check
> >> 3. We have the localhost check
> >> 4. The app is now installed under http://localhost:RANDOM_PORT/www/
> >>
> >> It'll be easy (relatively) to add support for:
> >> http://localhost:RANDOM_PORT/asset-library/
> >> http://localhost:RANDOM_PORT/file-system/
> >>
> >> The only issue now is changing FileEntry.toURL(). I'm thinking of some
> >> runtime 'magic' in the local web server where it detects the File
> plugin,
> >> and change the implementation of FileEntry.toURL() (or through injecting
> >> JavaScript, probably easier).
> >>
> >>
> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve <ag...@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 <sh...@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" <sh...@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)
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
included.
On Mon, Nov 17, 2014 at 2:47 PM, Shazron <sh...@gmail.com> wrote:
> Sorry I should have looked into the File API code first (no JavaScript
> changes, that would not work).
>
> Essentially I need to "override" this line from my plugin:
> https://github.com/apache/cordova-plugin-file/blob/82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/CDVAssetLibraryFilesystem.m#L74
> (plus the CDVLocalFileSystem equivalent).
>
> Since Obj-C categories can't really "override" methods (behavior
> undefined), and I don't want to do some runtime swap implementation voodoo,
> I would replace the line above with something like:
>
> NSString* nativeURL = [NSString stringWithFormat:@
> "assets-library:/%@",fullPath];
> if ([self respondsToSelector:@selector(nativeFullPath:)]) { // some
> unique selector name perhaps
> nativeURL = [self nativeFullPath:fullPath]; // this code won't
> compile, pseudo-code for now. Will call my category method defined in my
> plugin for CDVAssetLibraryFileSystem
> }
> dirEntry[@"nativeURL"] = nativeURL;
>
> Backwards compatible.
>
>
> On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com> wrote:
>
>> Local Web Server Checklist:
>> 1. We have random port usage
>> 2. We have the token/cookie check
>> 3. We have the localhost check
>> 4. The app is now installed under http://localhost:RANDOM_PORT/www/
>>
>> It'll be easy (relatively) to add support for:
>> http://localhost:RANDOM_PORT/asset-library/
>> http://localhost:RANDOM_PORT/file-system/
>>
>> The only issue now is changing FileEntry.toURL(). I'm thinking of some
>> runtime 'magic' in the local web server where it detects the File plugin,
>> and change the implementation of FileEntry.toURL() (or through injecting
>> JavaScript, probably easier).
>>
>>
>> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve <ag...@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 <sh...@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" <sh...@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)
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Sorry I should have looked into the File API code first (no JavaScript
changes, that would not work).
Essentially I need to "override" this line from my plugin:
https://github.com/apache/cordova-plugin-file/blob/82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/CDVAssetLibraryFilesystem.m#L74
(plus the CDVLocalFileSystem equivalent).
Since Obj-C categories can't really "override" methods (behavior
undefined), and I don't want to do some runtime swap implementation voodoo,
I would replace the line above with something like:
NSString* nativeURL = [NSString stringWithFormat:@
"assets-library:/%@",fullPath];
if ([self respondsToSelector:@selector(nativeFullPath:)]) { // some unique
selector name perhaps
nativeURL = [self nativeFullPath:fullPath]; // this code won't
compile, pseudo-code for now. Will call my category method defined in my
plugin for CDVAssetLibraryFileSystem
}
dirEntry[@"nativeURL"] = nativeURL;
Backwards compatible.
On Mon, Nov 17, 2014 at 1:44 PM, Shazron <sh...@gmail.com> wrote:
> Local Web Server Checklist:
> 1. We have random port usage
> 2. We have the token/cookie check
> 3. We have the localhost check
> 4. The app is now installed under http://localhost:RANDOM_PORT/www/
>
> It'll be easy (relatively) to add support for:
> http://localhost:RANDOM_PORT/asset-library/
> http://localhost:RANDOM_PORT/file-system/
>
> The only issue now is changing FileEntry.toURL(). I'm thinking of some
> runtime 'magic' in the local web server where it detects the File plugin,
> and change the implementation of FileEntry.toURL() (or through injecting
> JavaScript, probably easier).
>
>
> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve <ag...@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 <sh...@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" <sh...@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)
>> > > >
>> > >
>> >
>>
>
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Local Web Server Checklist:
1. We have random port usage
2. We have the token/cookie check
3. We have the localhost check
4. The app is now installed under http://localhost:RANDOM_PORT/www/
It'll be easy (relatively) to add support for:
http://localhost:RANDOM_PORT/asset-library/
http://localhost:RANDOM_PORT/file-system/
The only issue now is changing FileEntry.toURL(). I'm thinking of some
runtime 'magic' in the local web server where it detects the File plugin,
and change the implementation of FileEntry.toURL() (or through injecting
JavaScript, probably easier).
On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve <ag...@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 <sh...@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" <sh...@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)
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Andrew Grieve <ag...@chromium.org>.
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 <sh...@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" <sh...@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)
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
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" <sh...@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)
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Tommy Williams <to...@devgeeks.org>.
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" <sh...@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)
>