Fix/concurrent mitmweb instances overwrite each others mitmproxy auth cookie #7690
Conversation
|
LGTM aside from some nitpicks. Putting the port in the cookie name isn't my idea of an elegant solution, but it's probably the best way to solve #7651. |
I agree. Even if it's common to use a web page as UI for local tools, the technology is not really made for that so I think it's normal to need some workarounds. For that specific tool, I can really see the appeal of having more then one running. I just can't think of a cleaner solution. |
Actually, I lie here. I have an other idea but that would involve giving the proxy an API that the web page would interact with. This way, all the instances would be accessible from the same web page. We would have to use some kind of discovery method to automatically connect the web page to the instances. We could explore that alternative in the future. I don't really know how it would work yet. |
this separates concerns, `AuthRequestHandler` now has nothing mitmproxy-specific
97c21e7 to
2e71fa1
Compare
|
@turboOrange: I tried to simplify things a bit. PTAL, this is good to go from my end. :) |
Description
This is a fix for #7651.
The issue was that when two instances were running from the same domain or IP address, they shared cookies because cookies are tied to the domain, not the port. This made it difficult to run multiple instances on the same machine.
The solution proposed in this pull request is to include the port number in the cookie name. This ensures that even if cookies are technically shared at the domain level, they remain distinct and do not conflict.
Checklist