|
|
Post by jontara on May 22, 2017 6:37:00 GMT
Will it ever be possible to use iOS WKWebView with ios_direct_local_requests?
The problem is now App Store requires we support IPV6. And to support IPV6, I understand we need to use ios_direct_local_requests so that we can also disable ios_netcurl, since it doesn't support IPV6.
So, it is Catch-22.
For test, I disabled ios_direct_local_requests and enabled ios_netcurl and ios_use_WKWebView. There is no message in the log indicating that it is using WKWebView. But from behavior I can tell that it is, because the 300mSec click delay is gone due to using viewport meta. Click delay removal with viewport meta is support by WKWebView but not with UIWebView, so I know it must be WKWebView.
(Update: I guess I just missed it in the log before... yes, the log is showing RhoWebViewFabrique| WKWebView was created OK !)
Also, FYI, there is a bunch of binary data sent to the logfile at startup (and then normal logging starts) when ios_use_WKWebView is enabled.
|
|
|
|
Post by Dmitry Soldatenkov on May 24, 2017 23:47:15 GMT
So, you can not use WKWebView and ios_direct_local_requests=1 both. But you can use WKWebView and ios_direct_local_requests=0 + ios_net_curl=0 - in this case application will be support external ipv6 requests by Apple's requirements. But in this case you probably can have issues with some MDM solutions. Problem in WKWebView - HTTP requests from WKWebView can not be processed by NSURLProtocol listener functionality. P.S. I see some half-legal workaround, but currently do not implemented in Rhodes. For example - github.com/WildDylan/WKWebViewWithURLProtocol |
|
|
|
Post by jontara on May 25, 2017 2:12:00 GMT
Thank you Dmitry, that may work for me. I will try it. I am using WKWebView now, and I am very impressed with the performance. And there are generally some better behaviors from the WKWebView. I do not need to support MDM. I guess I assumed that because ios_direct_local_requests=1 requires ios_net_curl=0 then ios_direct_local_requests=0 requires ios_net_curl=1. I guess that was an incorrect assumption. Maybe the documentation and the comment in rhoconfig.txt. then could be clearer. My only concern then is one about security. Even though it is normally a random port (normally) my concern would be the ability to connect to the Rho server externally and be served pages, then discover endpoints exposed by the models, load pages, examine the Javascript, etc. etc. I wonder if there is some easy way to block external access? An option to bind the server to only 127.0.0.1 would be helpful. But I guess you could still access from another app on the device. Actually, yes, I just tested that from Mobile Safari and was able to access the Rho server on port 8080 (normally random). I had to go back and forth between apps to have the request fulfilled because server normally doesn't run in background. Is there perhaps some way to restrict access to the Rho server to only the WKWebView(s) that you create? Is it maybe possible to make 127.0.0.1 (or some other private address) sandboxed to the app? Otherwise, it is nice to know that at least it could be done for non-appstore products, like Enterprise Store with the workaround you linked. But the project I am using WKWebView on will have to be in app store. Potentially, students could cheat, but the nature of it is it would be like cheating at gym class!  |
|
|
|
Post by Dmitry Soldatenkov on May 25, 2017 10:20:34 GMT
Hi, we have two situations: 1. we use ios_direct_local_requests=1 and ios_net_curl=0 In this case there are no real socket server - we just processed all http requests inside application via NSURLProtocol functionality - you cannot connect from outside because there are no real server. 2. we use ios_direct_local_requests=0 and ios_net_curl=1 In this case we have real socket based server but socket configured to disable external connections. You can see in source code - when we want to open http server with external access in "development" extension - we special configure it for external connections. You can see special option in HTTP server constructor - github.com/rhomobile/rhodes/blob/master/platform/shared/net/HttpServer.h#L119 |
|
|
|
Post by jontara on May 26, 2017 7:19:59 GMT
Yes, but with ios_net_curl=1 then no support for IPv6, and will (eventually) get App Store rejection.
But I thought of an easy work-around.
Server might require a cookie with some secret key on every request. The server can just ignore the request and not even 404 if the key is not satisfied.
Since Rhodes has to force the very first navigation (initial page), that first page can have a little bit of Javascript that can set the value of the cookie.
But if a browser attempts to access the server, the browser will not have the matching cookie, and the server just doesn't respond.
On a jailbroken device, perhaps an attacker might use any one of a number of APIs to snoop, but the app can refuse to run on jailbroken device.
Maybe there could be some scheme to periodically change the key.
It may not be perfect, but would not be a sitting duck that requires only finding the port.
|
|
