Using Charles Debugging Proxy with Mobile Application Equipped with SeaCat

Developers of web and mobile applications often take advantage of using HTTP proxies to debug their applications. This allows them to check the headers and body of outgoing requests, related incoming responses, track possible flaws of their client application and server backend without any traffic interruption. You are able to perform the same function with mobile applications secured by SeaCat Mobile Secure Gateway.

Here is how you can easily do it by integrating Charles Web Debugging into the process.

What is HTTP debugging proxy?

HTTP debugging proxy is an intermediary service placed between a client and an application backend that can view information about requests and responses. It allows you to look at the communication headers and body to make sure that for instance proper cookies are sent and/or verify if application backend responses are correct to specific requests etc.

Usually, the development of mobile applications take place on one machine, typically the developer’s laptop where there is a running web server, a web browser and an HTTP debugging proxy that intercepts the browser's requests configured in the browser's setup.

A similar approach is taken when developing or troubleshooting a mobile application secured with SeaCat Mobile Secure Gateway.

Where to place Charles Proxy?

We are going to assume that you run your application in the emulator with SeaCat Mobile Secure Gateway and the application backend server running on your machine.

So the question is, where does Charles Proxy come in? The communication between the client and SeaCat Mobile Secure Gateway is secured; there is no way to read what data resides in the traffic. That is why we have to put Charles Proxy between SeaCat Gateway and the Application Backend. On your development machine we are looking towards a setup viewed here:

The point here is to let SeaCat Mobile Secure Gateway use Charles Proxy as its application backend while Charles Proxy reads and displays content of requests, forwards them to the application backend, reads and displays the response and sends it back to the SeaCat Mobile Secure Gateway that delivers it to the client.

Configuration

We will want to set up Charles Proxy to forward requests to our application backend and slightly change the SeaCat Mobile Secure Gateway’s configuration to use Charles Proxy as an application backend. This is achieved by setting up reverse proxies:

Charles Proxy Reverse Proxies

Open Charles Proxy and open the menu. In the menu navigate to Proxy → Reverse Proxies, click "add". Local Port will be automatically chosen by Charles Proxy so just copy the hostname from your SeaCat Mobile Secure Gateway configuration, put it in Remote Host and choose Remote Port. You should be able to set up as many proxies, as you have application backends listed in your SeaCat Mobile Secure Gateway configuration.

In our example, we assume there are two mobile applications requesting two different backends - one at eval.teskalabs.com, the other running on localhost.

SeaCat Mobile Secure Gateway Configuration

Now that we have the proxies all set, let’s make a copy of the SeaCat Mobile Secure Gateway’s configuration file and change application backends records to point to Charles Proxy’s appropriate ports.

cp seacat.conf seacat-debug.conf
vim seacat-debug.conf

Here is an example of application backends configuration assuming that we’re running the SeaCat Mobile Secure Gateway locally.

[host:evalhost]
; uri=http://eval.teskalabs.com:80 # not anymore
uri=http://127.0.0.1:60698

[host:app-backend]
; uri=http://127.0.0.1:5000 # not anymore
uri=http://127.0.0.1:60584

All we need to do now is to run SeaCat Mobile Secure Gateway with seacat-debug.conf configuration linked to it.

We're all set!

You can run your backend and use Charles Proxy to debug your mobile app secured by SeaCat Mobile Secure Gateway. You now have quick access to information like status codes, cookies, response/request times, etc.