cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy Williams <to...@devgeeks.org>
Subject Re: [iOS 8] WKWebView moving forward
Date Thu, 20 Nov 2014 19:12:45 GMT
Whew :)
On 21/11/2014 12:58 am, "Homer, Tony" <tony.homer@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" <shazron@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
> ><tommy@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" <shazron@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.homer@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" <shazron@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
> >><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
> >> >><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
> >> >>
> >> >>
> >>
> >>
> >>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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message