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 <shaz...@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 <agri...@chromium.org> > wrote: > >> We could restrict access to the webserver by stuffing a cookie into the >> webview with an access token, then have the server just 500 on any request >> missing the cookie. We should also be able to restrict external requests >> just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't look >> like GCDWebServer supports this, but we can hack it in). >> >> The problem of port conflicts is annoying though. Maybe we try random >> ports >> until one works? Is there any need to use the same port for multiple runs? >> >> The CORS thing is sad, because it also means things like Camera plugin >> will >> be broken (can't use resulting URL in <img>). >> >> Although we might just do (this is different than the current mapping in >> the plugin): >> http://localhost:RANDOM_PORT/www >> http://localhost:RANDOM_PORT/asset-library >> http://localhost:RANDOM_PORT/file-system >> >> to proxy the three locations. >> >> This also means we can't use FileEntry.toURL() and have it work, unless >> toURL returns http://localhost:RANDOM_PORT/file-system/... Maybe that's >> fine? >> >> >> I don't think it's weird that an app will need to support WKWebView on >> some >> OS versions, and UIWebView on others. That's already the case to support >> iOS 7. >> >> >> >> On Wed, Oct 29, 2014 at 6:22 PM, Shazron <shaz...@gmail.com> wrote: >> >> > This does not preclude using the file url API function I suppose. >> Here's a >> > flowchart on how I think it would work: http://i.imgur.com/zq4zreN.png >> > >> > >> > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams <to...@devgeeks.org> >> > wrote: >> > >> > > This whole thing reeks of sadness and pain. >> > > >> > > The security implications of this will have to be considered very >> > > carefully. >> > > On 29 Oct 2014 16:40, "Shazron" <shaz...@apache.org> wrote: >> > > >> > > > ## What We Know So Far >> > > > >> > > > 1. Because of the file:// url loading bug, we couldn't support the >> > > > WKWebView in the iOS 8 GM release. It has since been fixed, for >> release >> > > > post iOS 8.1 (not sure when), through a new WKWebView API function ( >> > > > http://trac.webkit.org/changeset/174029/trunk) >> > > > 2. The alternative is embedding a local web server and serving >> assets >> > > from >> > > > that >> > > > >> > > > ## Abandon file:// url Loading API Method >> > > > >> > > > My proposal is, we abandon the local file:// url loading method in >> (1) >> > > > above, since it will create problems with support. >> > > > >> > > > For example, if we support the new local file url loading API >> function >> > in >> > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2, what then? You >> would >> > > not >> > > > have WKWebView support for that user, and you would use UIWebView >> > > instead. >> > > > This will just be confusing, and leads to problems. >> > > > >> > > > With the embedded local web server method, you can support **any** >> > > version >> > > > of iOS 8.x. >> > > > >> > > > ## Embrace Embedded Local Web Server Method >> > > > >> > > > I have a Cordova plugin that implements this, and it should work >> with >> > > > cordova-ios 3.7.0: >> > > > https://github.com/shazron/CordovaLocalWebServer >> > > > >> > > > It dynamically updates the <access> tag value when it loads, >> overriding >> > > it >> > > > to the actual location and port. Since it is a plugin, it can be >> > > swappable >> > > > (for whatever reason). >> > > > >> > > > It does not solve the problem where any backgrounded app can access >> our >> > > > local web server. >> > > > >> > > > ## Future Steps >> > > > >> > > > This plugin is already working in cordova-ios 3.7.0 (un-released, up >> > next >> > > > for vote release). >> > > > >> > > > The wkwebview branch: >> > > > >> > > > 1. Needs be rebased >> > > > 2. Needs to be re-tested >> > > > 3. issues in CB-7043 that relate to the wkwebview have to be >> resolved >> > > > 4. branch presented for review to other committers >> > > > 5. resolve any comments and issues from (4) >> > > > 6. wkwebview branch integrated into master >> > > > >> > > > I will work on these items next after getting cordova-ios 3.7.0 out. >> > Any >> > > > help is welcome. >> > > > >> > > > ## Migration Issues >> > > > >> > > > If you are migrating to WKWebView from UIWebView, you will lose some >> > > > functionality. >> > > > >> > > > 1. No more whitelist feature (NSURLProtocol is not supported in >> > > WKWebView) >> > > > 2. Your XmlHttpRequest calls now need to be CORS compliant (this is >> > still >> > > > true if loaded through a file:// url) >> > > > 3. HTML5 offline application cache is not available in WKWebView ( >> > > > https://devforums.apple.com/message/1060452) >> > > > >> > > >> > >> > >
