2011-03-16 02:50:31 +00:00
|
|
|
|
2011-03-17 20:04:49 +00:00
|
|
|
When the __stickycookie__ option is set, __mitmproxy__ will add the cookie most
|
|
|
|
|
recently set by the server to any cookie-less request. Consider a service that
|
|
|
|
|
sets a cookie to track the session after authentication. Using sticky cookies,
|
|
|
|
|
you can fire up mitmproxy, and authenticate to a service as you usually would
|
|
|
|
|
using a browser. After authentication, you can request authenticated resources
|
|
|
|
|
through mitmproxy as if they were unauthenticated, because mitmproxy will
|
|
|
|
|
automatically add the session tracking cookie to requests. Among other things,
|
|
|
|
|
this lets you script interactions with authenticated resources (using tools
|
|
|
|
|
like wget or curl) without having to worry about authentication.
|
|
|
|
|
|
|
|
|
|
Sticky cookies are especially powerful when used in conjunction with [client
|
|
|
|
|
replay](@!urlTo("clientreplay.html")!@) - you can record the authentication
|
|
|
|
|
process once, and simply replay it on startup every time you need to interact
|
|
|
|
|
with the secured resources.
|
2011-03-16 02:50:31 +00:00
|
|
|
|
|
|
|
|
|
2011-03-20 04:31:54 +00:00
|
|
|
## Sticky auth
|
|
|
|
|
|
2011-03-29 23:05:50 +00:00
|
|
|
The __stickyauth__ option is analogous to the __stickycookie__ option, in that
|
2011-03-20 04:31:54 +00:00
|
|
|
HTTP __Authorization__ headers are simply replayed to the server once they have
|
|
|
|
|
been seen. This is enough to allow you to access a server resource using HTTP
|
|
|
|
|
Basic authentication through the proxy. Note that __mitmproxy__ doesn't (yet)
|
|
|
|
|
support replay of HTTP Digest authentication.
|
