## Sticky cookies

When the sticky cookie 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.

<table class="table">
    <tbody>
        <tr>
            <th width="20%">command-line</th>
            <td>
                <ul>
                    <li>-t FILTER</li>
                </ul>
            </td>
        </tr>
        <tr>
            <th>mitmproxy shortcut</th> <td><b>o</b> then <b>t</b></td>
        </tr>
    </tbody>
</table>


## Sticky auth

The sticky auth option is analogous to the sticky cookie option, in that 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.

<table class="table">
    <tbody>
        <tr>
            <th width="20%">command-line</th>
            <td>
                <ul>
                    <li>-u FILTER</li>
                </ul>
            </td>
        </tr>
        <tr>
            <th>mitmproxy shortcut</th> <td><b>o</b> then <b>A</b></td>
        </tr>
    </tbody>
</table>