2014-01-27 01:16:23 +00:00
__mitmproxy__ has a powerful scripting API that allows you to modify flows
2014-08-06 23:30:47 +00:00
on-the-fly or rewrite previously saved flows locally.
2014-01-27 01:16:23 +00:00
The mitmproxy scripting API is event driven - a script is simply a Python
module that exposes a set of event methods. Here's a complete mitmproxy script
that adds a new header to every HTTP response before it is returned to the
client:
$!example("examples/add_header.py")!$
The first argument to each event method is an instance of ScriptContext that
lets the script interact with the global mitmproxy state. The __response__
event also gets an instance of Flow, which we can use to manipulate the
response itself.
We can now run this script using mitmdump or mitmproxy as follows:
< pre class = "terminal" >
> mitmdump -s add_header.py
< / pre >
The new header will be added to all responses passing through the proxy.
## Events
### start(ScriptContext, argv)
Called once on startup, before any other events.
2014-09-05 13:16:20 +00:00
### clientconnect(ScriptContext, ConnectionHandler)
2014-01-27 01:16:23 +00:00
Called when a client initiates a connection to the proxy. Note that
a connection can correspond to multiple HTTP requests.
2014-09-05 13:16:20 +00:00
### serverconnect(ScriptContext, ConnectionHandler)
2014-01-27 01:16:23 +00:00
Called when the proxy initiates a connection to the target server. Note that
a connection can correspond to multiple HTTP requests.
2014-09-05 13:16:20 +00:00
### request(ScriptContext, HTTPFlow)
2014-01-27 01:16:23 +00:00
2014-09-05 13:16:20 +00:00
Called when a client request has been received. The __HTTPFlow__ object is
2014-01-27 01:16:23 +00:00
guaranteed to have a non-None __request__ attribute.
2014-09-05 13:16:20 +00:00
### responseheaders(ScriptContext, HTTPFlow)
2014-07-25 02:11:16 +00:00
Called when the headers of a server response have been received.
This will always be called before the response hook.
2014-09-05 13:16:20 +00:00
The __HTTPFlow__ object is guaranteed to have non-None __request__ and
__response__ attributes. __response.content__ will be None,
2014-07-25 02:11:16 +00:00
as the response body has not been read yet.
2014-01-27 01:16:23 +00:00
2014-09-05 13:16:20 +00:00
### response(ScriptContext, HTTPFlow)
2014-01-27 01:16:23 +00:00
2014-09-05 13:16:20 +00:00
Called when a server response has been received. The __HTTPFlow__ object is
2014-01-27 01:16:23 +00:00
guaranteed to have non-None __request__ and __response__ attributes.
2014-07-25 02:11:16 +00:00
Note that if response streaming is enabled for this response,
__response.content__ will not contain the response body.
2014-01-27 01:16:23 +00:00
2014-09-05 13:16:20 +00:00
### error(ScriptContext, HTTPFlow)
2014-01-27 01:16:23 +00:00
Called when a flow error has occurred, e.g. invalid server responses, or
interrupted connections. This is distinct from a valid server HTTP error
2014-09-05 13:16:20 +00:00
response, which is simply a response with an HTTP error code. The __HTTPFlow__
2014-01-27 01:16:23 +00:00
object is guaranteed to have non-None __request__ and __error__ attributes.
2014-09-05 13:16:20 +00:00
### clientdisconnect(ScriptContext, ConnectionHandler)
2014-01-27 01:16:23 +00:00
Called when a client disconnects from the proxy.
### done(ScriptContext)
Called once on script shutdown, after any other events.
## API
The main classes you will deal with in writing mitmproxy scripts are:
< table class = "table" >
< tr >
2014-03-10 16:01:30 +00:00
< th > libmproxy.proxy.server.ConnectionHandler< / th >
2014-08-06 23:30:47 +00:00
< td > Describes a proxy client connection session. Always has a client_conn attribute, might have a server_conn
attribute.
< / td >
2014-01-27 01:16:23 +00:00
< / tr >
< tr >
2014-03-10 16:01:30 +00:00
< th > libmproxy.proxy.connection.ClientConnection< / th >
< td > Describes a client connection.< / td >
< / tr >
2014-08-06 23:30:47 +00:00
< tr >
2014-03-10 16:01:30 +00:00
< th > libmproxy.proxy.connection.ServerConnection< / th >
< td > Describes a server connection.< / td >
2014-01-27 01:16:23 +00:00
< / tr >
< tr >
2014-03-10 16:01:30 +00:00
< th > libmproxy.protocol.http.HTTPFlow< / th >
2014-01-27 01:16:23 +00:00
< td > A collection of objects representing a single HTTP transaction.< / td >
< / tr >
< tr >
2014-03-10 16:01:30 +00:00
< th > libmproxy.protocol.http.HTTPResponse< / th >
2014-01-27 01:16:23 +00:00
< td > An HTTP response.< / td >
< / tr >
< tr >
2014-03-10 16:01:30 +00:00
< th > libmproxy.protocol.http.HTTPRequest< / th >
2014-01-27 01:16:23 +00:00
< td > An HTTP request.< / td >
< / tr >
2014-09-05 13:16:20 +00:00
< tr >
< th > libmproxy.protocol.primitives.Error< / th >
< td > A communications error.< / td >
< / tr >
2014-01-27 01:16:23 +00:00
< tr >
2014-03-10 16:01:30 +00:00
< th > libmproxy.script.ScriptContext< / th >
2014-08-06 23:30:47 +00:00
< td > A handle for interacting with mitmproxy's from within scripts.< / td >
2014-01-27 01:16:23 +00:00
< / tr >
2014-09-05 13:16:20 +00:00
< tr >
< th > libmproxy.flow.ODict< / th >
< td > A dictionary-like object for managing sets of key/value data. There
is also a variant called CaselessODict that ignores key case for some
calls (used mainly for headers).
< / td >
< / tr >
2014-01-27 01:16:23 +00:00
< tr >
< th > libmproxy.certutils.SSLCert< / th >
< td > Exposes information SSL certificates.< / td >
< / tr >
< / table >
The canonical API documentation is the code. You can view the API documentation
using pydoc (which is installed with Python by default), like this:
< pre class = "terminal" >
2014-03-10 16:01:30 +00:00
> pydoc libmproxy.protocol.http.HTTPRequest
2014-01-27 01:16:23 +00:00
< / pre >
## Running scripts in parallel
We have a single flow primitive, so when a script is handling something, other requests block.
While that's a very desirable behaviour under some circumstances, scripts can be run threaded by using the < code > libmproxy.script.concurrent< / code > decorator.
$!example("examples/nonblocking.py")!$
2014-08-06 23:30:47 +00:00
## Make scripts configurable with arguments
Sometimes, you want to pass runtime arguments to the inline script. This can be simply done by surrounding the script call with quotes, e.g.
< code > mitmdump -s "script.py --foo 42"< / code > . The arguments are then exposed in the start event:
$!example("examples/modify_response_body.py")!$
2014-01-27 01:16:23 +00:00
## Running scripts on saved flows
Sometimes, we want to run a script on __Flow__ objects that are already
complete. This happens when you start a script, and then load a saved set of
flows from a file (see the "scripted data transformation" example on the
[mitmdump](@!urlTo("mitmdump.html")!@) page). It also happens when you run a
one-shot script on a single flow through the _|_ (pipe) shortcut in mitmproxy.
In this case, there are no client connections, and the events are run in the
2014-09-05 13:16:20 +00:00
following order: __start__, __request__, __responseheaders__, __response__, __error__, __done__. If
2014-01-27 01:16:23 +00:00
the flow doesn't have a __response__ or __error__ associated with it, the
2014-09-05 13:16:20 +00:00
matching events will be skipped.
2014-08-06 23:30:47 +00:00
## Spaces in the script path
By default, spaces are interpreted as separator between the inline script and its arguments (e.g. < code > -s "foo.py
42"< / code > ). Consequently, the script path needs to be wrapped in a separate pair of quotes if it contains spaces:
< code > -s "'./foo bar/baz.py' 42"< / code > .