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" <shaz...@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.ho...@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" <shaz...@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 <tony.ho...@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" <shaz...@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 >><iclell...@chromium.org> >> >> >wrote: >> >> > >> >> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse <purplecabb...@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 >> >><agri...@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 <shaz...@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 <shaz...@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 >><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) >> >> >> > > > >>> > > > >> >> >> > > > >>> > > >> >> >> > > > >>> > >> >> >> > > > >>> >> >> >> > > > >> >> >> >> > > > >> >> >> >> > > > > >> >> >> > > > >> >> >> > > >> >> >> > >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> >> For additional commands, e-mail: dev-h...@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-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
