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.sh...@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.ho...@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" <agri...@chromium.org> wrote: > > >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <shaz...@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 <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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
