You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Atlantis library has been really useful because I couldn't get a working setup with just the Proxyman macOS app due to VPN issues (though have just managed to hopefully finally resolve that by using the allow-list!) and Alantis actually managed to get network logs working!
But there were some quirks regarding how Atlantis intercepts the network traffic and my app's own networking complexities conflicted (both use URLProtocol). It basically meant that the network logs weren't showing an accurate or stable picture of what was conceptually happening.
Largely this was down to my networking code intercepting looking for specific error responses to requests within my URLProtocol and then replaying the request differently to get a successful response (relating to handling custom authentication challenges).
I've put together a simple sample app that illustrates the difference between using Atlantis and not in this sort of scenario: AtlantisTest.zip
The sample app sends a request that gets a 404 response, catches that in my URLProtocol and then makes another request that gets a 200 and reports that result to the request that made the 404 request. So the original request doesn't know about the replay, but gets the result that it really wanted (it's a simplified example so might not make a huge amount of sense!)
Without Atlantis without atlantis.proxymanlog.zip
Just see the two requests, with IDs ordered the same as their timestamps, which is what I'd hope for as this is the reality
With Atlantis with atlantis.proxymanlog.zip
See four requests, with IDs that don't match the order of the timestamps. This obviously makes it hard to look at exported network logs and make sense of what was really going on.
Not sure if there's a huge amount that can be done about this though! Even if I register my URLProtocol before or after starting Atlantis the result is the same.
The text was updated successfully, but these errors were encountered:
The Atlantis library has been really useful because I couldn't get a working setup with just the Proxyman macOS app due to VPN issues (though have just managed to hopefully finally resolve that by using the allow-list!) and Alantis actually managed to get network logs working!
But there were some quirks regarding how Atlantis intercepts the network traffic and my app's own networking complexities conflicted (both use
URLProtocol
). It basically meant that the network logs weren't showing an accurate or stable picture of what was conceptually happening.Largely this was down to my networking code intercepting looking for specific error responses to requests within my
URLProtocol
and then replaying the request differently to get a successful response (relating to handling custom authentication challenges).I've put together a simple sample app that illustrates the difference between using Atlantis and not in this sort of scenario:
AtlantisTest.zip
The sample app sends a request that gets a 404 response, catches that in my
URLProtocol
and then makes another request that gets a 200 and reports that result to the request that made the 404 request. So the original request doesn't know about the replay, but gets the result that it really wanted (it's a simplified example so might not make a huge amount of sense!)Without Atlantis without atlantis.proxymanlog.zip
Just see the two requests, with IDs ordered the same as their timestamps, which is what I'd hope for as this is the reality
With Atlantis with atlantis.proxymanlog.zip
See four requests, with IDs that don't match the order of the timestamps. This obviously makes it hard to look at exported network logs and make sense of what was really going on.
Not sure if there's a huge amount that can be done about this though! Even if I register my
URLProtocol
before or after starting Atlantis the result is the same.The text was updated successfully, but these errors were encountered: