Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of shazron@gmail.com designates
 209.85.216.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAE6O_-Zzg7RUsvavCuf_wUO8fC+1z09FukPT_ZH1ybXOueP4fw@mail.gmail.com>
References: 
 <CAE6O_-aBHmyw6SKVHuuUZCxYaiaK4v2qh8401K2-SbtPtgm+7w@mail.gmail.com>
 <CAPTyS6DtkdNkkDGVe5bAwRTXUsBK7w_WHa4NDV4Rkrdf9uAQfA@mail.gmail.com>
 <CAE6O_-YsR9CN2GO8T6kkL13EzpQk4HhALV83wi4SKmz9qfFiMg@mail.gmail.com>
 <CABiQX1V7Y18-n=L97S+rwgNH_cMR0GWV4wm0JQ9FGs_1ty_E4g@mail.gmail.com>
 <CAE6O_-Zzg7RUsvavCuf_wUO8fC+1z09FukPT_ZH1ybXOueP4fw@mail.gmail.com>
From: Shazron <shazron@gmail.com>
Date: Mon, 17 Nov 2014 14:47:00 -0800
Message-ID: 
 <CAE6O_-YzvFwL64Rt87P6Ow1CfbpSfJoZDuCzfcTPzRV14Bx58Q@mail.gmail.com>
Subject: Re: [iOS 8] WKWebView moving forward
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=089e015373b61ce317050815c43b

--089e015373b61ce317050815c43b
Content-Type: text/plain; charset=UTF-8

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 <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)
>> > > >
>> > >
>> >
>>
>
>

--089e015373b61ce317050815c43b--