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.
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.
|Local Port||Remote Host||Remote Port|
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.
Data encryption tool for GDPRMore information
You Might Be Interested in Reading These Articles
As the market with Cloud Computing and Mobile devices is getting bigger, there is another specific option available. It's called (Mobile)Backend-As-A-Service (BAAS) and it is extremely useful in situations we want to subscribe a complex backend service (alongside the core backend solution, there is usually a lot of additional functionality and statistics) and primary focus on development of client part of mobile apps for instance.
Published on January 31, 2015
One of the most exciting tasks for our team in the last month was to create a new application server “boilerplate” that would be used as a basis for most of our growing data-processing products, as well as for other people and companies ...
Published on January 16, 2018
Asynchronous Server App Boilerplate (or ASAB for short) is a microservice platform for Python 3.5+ and asyncio. The aim of ASAB is to minimize the amount of code that needs to be written when building a microservice or an aplication server.
Published on May 01, 2019