cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tommy-carlos williams <to...@devgeeks.org>
Subject Re: [iOS 8] WKWebView moving forward
Date Thu, 20 Nov 2014 00:23:12 GMT
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#comm  
>>>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?KK[XZ[?]?][??X?昧?X?P白???K?\X?K????B????Y][??[栢[X[??K[XZ[?]?Z[白???K?\X?K????B
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message