This one in turn uses certifi to create its trusted certificate store, which didn’t have a copy of mitmproxy’s root certificate causing all https calls being silenced and not exiting the container. Our Django app uses the Requests library to execute http calls. It took me a while to figure out what was going on. I could run a curl command inside the container to an https endpoint and it flowed through mitmproxy like a boss, but when I started the Django app, https requests kept being aborted. Initially I tried to add the certificate to the container’s OS trusted certificate store, but that didn’t work out as planned. ![]() As a result, the requests will get blocked as the OS doesn’t trust that certificate (like it should). The reason is that mitmproxy uses it’s own certificate to be able to decrypt the traffic flowing through. If you’d only use the proxy settings, http requests would enter mitmproxy just fine, but https requests will not show up. Now, you might notice there’s another little item in there called python3 certificate.py which runs just before we start the Django app. The ip address 10.125.2.187 is the one of my host machine, change it to whatever yours is. These tell the container to route all exiting traffic towards mitmproxy, who’s added as an extra host. You can see two environment variables, HTTP_PROXY and HTTPS_PROXY. In the above example I only added the settings relevant to illustrate the solution. Version: '2' services: mv-web: environment: - HTTP_PROXY=mitmproxy: 8080 - HTTPS_PROXY=mitmproxy: 8080 extra_hosts: - "mitmproxy:10.125.2.187" command: sh -c 'python3 certificate.py & python3 manage.py runserver 0.0.0.0:8020' The default port for capturing traffic is 8080, change it using the -p option in case conflicts would occur. Before doing anything else, start mitmproxy and get comfortable. I’m running it using the WSL on Windows myself (Ubuntu). Installing mitmproxy is a breeze, as it’s a cross platform tool, you can follow the installation guide for your platform. In this case, I have a Python Django web app running in a Debian Jessie container and I needed to see the flow of requests being made towards the backend REST API. Otherwise we’d still be adding print statements everywhere just for the sake of debugging (I know you’re doing it). All in all, there’s a significant gain in lead time when using the right tool for the job. Or, use the proxy to alter requests and easily test use cases or reproduce bug reports. Coming from an app development background myself, it can be a huge benefit to use proxy tooling like mitmproxy to see the actual request being made instead of staying stuck trying to figure out what’s wrong. ![]() You are working on an application running inside a docker container and you feel the need to inspect the http requests being executed by your application.
0 Comments
Leave a Reply. |