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.
Most Recent Articles
- Creative Dock, TeskaLabs, Indermedica, Czech Ministry of Industry and Trade and Line 1212 launch the indicative test for new COVID-19 coronavirus
- Cyber-health with a password and an antivirus program is not enough
- TeskaLabs at the ETSI 1st C-V2X Plugtest
- TeskaLabs has become a leader of Mobile Healthcare applications in the Health (in) Future Platform
- TeskaLabs at the ETSI 7th CMS Plugtest validating C-ITS security
You Might Be Interested in Reading These Articles
The goal of this article is to extend the knowledge and develop an iOS application which is able to comunicate with REST interface provided by Node.js that we are going to create as well. A full integration with SeaCat is essential for information security of our example.
Published on October 07, 2014
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
The previous tutorial introduces several concepts and helps you understand the basic of REST API integration with iOS client written in Swift. There are several limitations, with data storage being the most important. This article provides instructions on how to work around this restriction.
Published on November 25, 2014