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
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.
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
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