I'm using GCDWebServer as a local HTTP server, serving data.
Another part of my application base on a WKWebView consume this data.
So while the data is travelling between the two, it's unencrypted and available to anyone (correct me if I'm wrong)? How dangerous would that be, on a non jailbroken iOS device?
Problem:
GCDWebServer doesn't support HTTPS : "What's not supported (but not really required from an embedded HTTP server): - HTTPS / - Keep Alive"
WKWebViews doesn't allow you to intercept incoming data for pre-treatment. "WKWebView makes requests and renders content out-of-process, meaning your app does not hear the requests they make"
Any solution other than picking a new local WebServer?
Related
When I use Charles Proxy for iOS and play some games, I recognize that they etablish connections with the protocol prefix "socket://" followed by an IP address (instead of a hostname, which is always present for other HTTP(s) connections). I'd assume that those are websockets.
Currently, I'm trying to implement a tool to track rudimentary network activity. To archive that, I'm using the NEKit (https://zhuhaow.me/NEKit/) in combination with the NEPacketTunnelProvider extension for iOS. Using that, I was able to set up a local HTTP Proxy server and setup the network interface to redirect every HTTP(s) request over that local proxy. Through an observer, I was able to see all the requested hostnames.
Now I found out, that some games (those which are using websockets) are not working properly with my solution. Regarding to this discussion https://news.ycombinator.com/item?id=16694670 it seems like proxying the HTTP(s) data flow doesn't enable me to handle websocket connections:
Yes, but the problem with Charles (well, iOS related at least) is that iOS websockets don't go through the HTTP Proxy configured. They're just considered a raw socket. Thus, even on desktop Charles, it's a nogo.
Due to that, some apps don't even work when my tracker is enabled, since they can't etablish a connection to their servers.
Is there the possibility to archive something similar for the websocket connections since the combination of GCDHTTPProxyServer (NEKit) and NEProxySettings (NetworkExtension) is only working for HTTP(s)? How can I track and (even better) proxy websocket connections?
I have a problem when loading the local web from WKWebView in iOS8. There are some suggestions that I should use GCDWebServer. I read through GCDWebServer, but not really understand what GCDWebServer is for on mobile application's side.
Could you give me any practical case of using this library? Sorry for my ignorance.
It's a webserver that you can run on your iOS device. Just like you would run a webserver on VPS or dedicated server providers.
This webserver that you would run and host from your iOS app will of course be available only in the network your iOS device is connected to.
This makes it useful for you to write client programs or scripts on other machines but connected to that network, to call your iOS app (running the GCDWebServer) to upload or download files that you so choose to store in your iOS app's sandboxes document directory for instance. Or as simple as viewing HTML or other data - plain text or json - served by GCDWebServer.
It had nothing to do with what WKWebView. WKWebView is a 'simplified WebKit browser client' that you can implement in your iOS app to view web pages served from other webserver hosts.
You can think of WKWebView as the complete opposite of GCDWebServer.
We can use GCDWebServer has a network interceptor in ios. You can intercept any HTTP requests happening inside WKWebView. For example, you can use GCDWebServer to handle caching and parallel processing for your expensive API requests. You can immediately return some cached responses and later redirect the URL to the actual destination.
I just wonder why and for what kind of application or case we need the Socket.IO.
I am the iOS developer of a known open source project socket.IO-objc
Usually, we need HTTP or HTTPS to communicate with server. The socket aims to conduct real time communication (It should always keep a live HTTP connection.)
Libraries like socket.IO are needed when we need real-time in our app. Let me explain this in little more detail. Let's assume that you are developing a game, which is multiplayer and 2 or more users can play that simultaneously. Then, in that case, you won't be making HTTP or HTTPS calls because of many reasons and one of them is that their packet size is large and other is that these calls are very slow. In such scenarios we use libraries like sockets to send and receive data to and from the server. Sockets are really fast and are capable of sending only those data packets which are needed. Using HTTP programming you can never create any multiplayer game or any app which will be interacting with a server on a realtime basis.
Let's take another example. Let's assume that you are working on a chat application. When user A is typing something then user B should know that A is typing (similar to gtalk of facebook messenger). If you will use HTTP calls at that point of time then "B" will never be able to see the actual status of the other person because of the delay. So what we can use is sockets so that when user A is typing anything then his device will send only one data packet which will just notify the server that he is typing and will be delivered to user B, this process is really fast (almost realtime) and will reduce the data transfer also.
I'm working on chat application using socket.io also. So it seems to replacing everythings with socket.io. This is making me in doubt and curiousness. I totally agree with real-time app like chat suits for socket.io. However there is round-trip communication (such as user login) that's more suitable for HTTP.
Socket.io uses web socket to pass data among users who are all connected to a web server. With web socket, there is no negotiation protocols and connection remain open as long as users concerned are registering for service with the web server. As pointed out also, the payload is significantly less than http/https protocol.
Socket.IO is a JavaScript library for realtime web applications. It enables realtime, bi-directional communication between web clients and server. It has two parts: a client-side library that runs in the browser, and a server-side library for node.js. Both components have a nearly identical API.
I am working on an ios app which communicate with the server via http request. And I want to monitor the network traffic when testing my app in ios simulator/devices.
Is there any software or tools I can used to inspect the http requests of a specified application on mac/ios, just like firebugs for web developers?
Thanks.
As far as I know, there are several tools in App Store that provide the network traffic monitor feature. But, they could only view iPhone as a whole and stay at that level. In other words, they could only tell how much traffic has been consumed of this iPhone. For each app? No data.
You can use HTTP Catcher to capture web traffic. It's a Web debugging proxy for iOS, so you can view requests and responses directly on iPhone.
You can use Proxyman to record/capture all the requests & responses from your app while developing.It will support ios simulators also. Without doing any code change we use this.
First Download the Proxyman app form the above link after that just go through this documentation for references.
Charles has recently released an iOS version for http traffic monitoring. it is a paid app though. Good news is that you can set up Charles free desktop version then setup HTTP proxy from your iOS device.
Assuming I have implement that :
making my app as a server which means in safari I can connect to the app if I input http://url-link.
My question is : if I request http:// url-link/doc, and the server - that is my app can return the content in document directory.
I don't know how to write the web service in iPhone.
As I'm fresh to web service, can any one help me?
thanks
This is one possibility: Cocoa HTTP Server. From the project's page:
So with Apple's framework for an HTTP
server tucked under our arm we set out
to make our own. We wanted the
following:
Built in support for bonjour broadcasting
IPv4 and IPv6 support
Asynchronous networking using standard Cocoa sockets/streams
Digest access authentication
TLS encryption support
Extremely FAST and memory efficient
Heavily commented code
Very easily extensible
You can link this library from your app and effectively make it a mini-web server.