In an earlier post, from a few months ago, I wrote about how I was Investigating Issues with the Moodle Mobile app that our clients at NetSpot had reported. Since that original post I’ve refined my methodology, and wanted to take this opportunity to write an updated post. I’ll break the post into two parts, first the hardware, and then the software.
The computer hardware that I use for testing can be seen in the photograph of my desk at NetSpot below.
The hardware specific to testing mobile apps is an iPad Mini, an iPhone (used to take the picture) and a USB powered TP-Link TL-MR3020, WiFi router. I’ve updated the firmware on the router to the latest OpenWrt firmware. I updated the firmware to OpenWrt to make it easier for me to manage the device.
The router is configured to use a network in the 172.16.1.* range. Which is range that is not used either at work, or at home. Indeed I’ve never seen this range used in a real life network. The devices that I connect to the WiFi network are configured to use a proxy server at a statically defined address. This address is assigned to the USB network adapter connected to my MacBook Pro.
In this way I have a private network that I can connect my devices to. Additionally it is a network that I have complete control over. Importantly the only traffic on the network is from my devices. Lastly all HTTP and HTTPS traffic must go through a proxy server running on my MacBook. This is important as it makes it easier to capture the traffic for analysis.
I use two different proxy servers depending on the type of issue I’m investigating. I usually start by using Tinyproxy, as it is really simple to setup and works really well. As with many of these types of applications I installed it using Homebrew. Using the TinyProxy logs I can see which URLs are being requested.
This is important, because an app running on the iPhone or iPad Mini is a black box which you don’t have much insight into. By using a proxy server I can at least see the web requests that the app makes. I prefer to test the app, or mobile theme, on a real device. In my experience, while emulators do a fine job, they are no substitute for testing on an actual device.
One thing that Tinyproxy doesn’t do, is allow me to see the content of the requests or responses. This is especially true when the requests are made using HTTPS.
To see the content of the requests and responses, including those made using HTTPS, I use mitmproxy. Using mitmproxy I can capture the requests made by the app, and the responses from the web server in real time. This is very useful.
Additionally it is possible to add a certificate to the device so that HTTPS traffic can be captured without any warnings being displayed. Or the app that I’m testing throwing an error.
Using this hardware and software I have been able to successfully debug issues with mobile websites and mobile applications, such as the Moodle Mobile app. As one of my colleagues noted, this solution is over engineered somewhat. It is possible to have my iPhone connect to a proxy server on my MacBook Pro via the corporate network. There are three additional considerations to the setup.
First, running services on my MacBook that others can connect to, on the corporate network, makes me uncomfortable. Second, in the past I have used Wireshark to capture network packets. The thought of capturing packets that I shouldn’t also makes me uncomfortable.
Lastly to get things up and running all I need to do is plug the WiFi router in, connect the device to the WiFi network and I’m good to go. Both at work in the office, or when I’m working at home.
My solution isn’t for everyone, as I’m sure there are alternative ways of doing things. What’s important is that it works for me.