mirror of
https://github.com/Grasscutters/mitmproxy.git
synced 2025-02-01 15:55:28 +00:00
modifybody addon: update docs
This commit is contained in:
Martin Plattner
parent
b263b0dece
commit
4cffbec291
@ -11,10 +11,10 @@ menu:
|
||||
|
||||
- [Anticache](#anticache)
|
||||
- [Client-side replay](#client-side-replay)
|
||||
- [Modify Body](#modify-body)
|
||||
- [Modify Headers](#modify-headers)
|
||||
- [Proxy Authentication](#proxy-authentication)
|
||||
- [Replacements](#replacements)
|
||||
- [Server-side replay](#server-side-replay)
|
||||
- [Set Headers](#set-headers)
|
||||
- [Sticky Auth](#sticky-auth)
|
||||
- [Sticky Cookies](#sticky-cookies)
|
||||
- [Streaming](#streaming)
|
||||
@ -41,30 +41,22 @@ conversation, where requests may have been made concurrently.
|
||||
You may want to use client-side replay in conjunction with the `anticache`
|
||||
option, to make sure the server responds with complete data.
|
||||
|
||||
## Proxy Authentication
|
||||
|
||||
Asks the user for authentication before they are permitted to use the proxy.
|
||||
Authentication headers are stripped from the flows, so they are not passed to
|
||||
upstream servers. For now, only HTTP Basic authentication is supported. The
|
||||
proxy auth options are not compatible with the transparent, socks or reverse
|
||||
proxy mode.
|
||||
## Modify Body
|
||||
|
||||
|
||||
## Replacements
|
||||
|
||||
The `replacements` option lets you specify an arbitrary number of patterns that
|
||||
define text replacements within flows. A replacement pattern looks like this:
|
||||
The `modify-body` option lets you specify an arbitrary number of patterns that
|
||||
define replacements within bodies of flows. A replacement pattern looks like this:
|
||||
|
||||
{{< highlight none >}}
|
||||
/patt/regex/replacement
|
||||
[/patt]/regex/replacement
|
||||
{{< / highlight >}}
|
||||
|
||||
Here, **patt** is a mitmproxy filter expression that defines which flows a
|
||||
replacement applies to, **regex** is a valid Python regular expression that
|
||||
defines what gets replaced, and **replacement** is a string literal that is
|
||||
substituted in. The separator is arbitrary, and defined by the first character.
|
||||
If the replacement string literal starts with `@`, it is treated as a file path
|
||||
from which the replacement is read.
|
||||
Here, **patt** is a mitmproxy [filter expression]({{< relref "concepts-filters">}})
|
||||
that defines which flows a replacement applies to, **regex** is a valid Python
|
||||
regular expression that defines what gets replaced, and **replacement** is a string
|
||||
literal that is substituted in. The separator is arbitrary, and defined by the
|
||||
first character. If the replacement string literal starts with `@`, it is treated
|
||||
as a file path from which the replacement is read.
|
||||
|
||||
Replace hooks fire when either a client request or a server response is
|
||||
received. Only the matching flow component is affected: so, for example,
|
||||
@ -76,7 +68,7 @@ to create a script using the replacement API on Flow components.
|
||||
|
||||
### Examples
|
||||
|
||||
Replace `foo` with `bar` in requests:
|
||||
Replace `foo` with `bar` in bodies of requests:
|
||||
|
||||
{{< highlight none >}}
|
||||
:~q:foo:bar
|
||||
@ -85,10 +77,39 @@ Replace `foo` with `bar` in requests:
|
||||
Replace `foo` with the data read from `~/xss-exploit`:
|
||||
|
||||
{{< highlight bash >}}
|
||||
mitmdump --replacements :~q:foo:@~/xss-exploit
|
||||
mitmdump --modify-body :~q:foo:@~/xss-exploit
|
||||
{{< / highlight >}}
|
||||
|
||||
|
||||
## Modify Headers
|
||||
|
||||
The `modify_headers` option lets you specify a set of headers to be modified.
|
||||
New headers can be added, and existing headers can be overwritten or removed.
|
||||
A `modify_headers` expression looks like this:
|
||||
|
||||
{{< highlight none >}}
|
||||
/name/value[/filter-expression]
|
||||
{{< / highlight >}}
|
||||
|
||||
Here, **name** and **value** are the header name and the value to set respectively,
|
||||
e.g., ``/Host/example.org``. An empty **value** removes existing headers with
|
||||
**name**, e.g., ``/Host/``. The optional **filter-expression** is a mitmproxy
|
||||
[filter expression]({{< relref "concepts-filters">}}) that defines
|
||||
which flows to modify headers on, e.g., only on responses using ``~s``.
|
||||
Existing headers are overwritten by default.
|
||||
This can be changed using filter-expressions, e.g., ``!~h Host:`` to ignore
|
||||
requests and responses with an existing ``Host`` header.
|
||||
|
||||
|
||||
## Proxy Authentication
|
||||
|
||||
Asks the user for authentication before they are permitted to use the proxy.
|
||||
Authentication headers are stripped from the flows, so they are not passed to
|
||||
upstream servers. For now, only HTTP Basic authentication is supported. The
|
||||
proxy auth options are not compatible with the transparent, socks or reverse
|
||||
proxy mode.
|
||||
|
||||
|
||||
## Server-side replay
|
||||
|
||||
The `server_replay` option lets us replay server responses from saved HTTP
|
||||
@ -131,24 +152,6 @@ then the respective recorded responses are simply replayed by mitmproxy.
|
||||
Otherwise, the unmatched requests is forwarded to the upstream server. If
|
||||
forwarding is not desired, you can use the --kill (-k) switch to prevent that.
|
||||
|
||||
## Modify Headers
|
||||
|
||||
The `modify_headers` option lets you specify a set of headers to be modified.
|
||||
New headers can be added, and existing headers can be overwritten or removed.
|
||||
A `modify_headers` expression looks like this:
|
||||
|
||||
{{< highlight none >}}
|
||||
/name/value[/filter-expression]
|
||||
{{< / highlight >}}
|
||||
|
||||
Here, **name** and **value** are the header name and the value to set respectively,
|
||||
e.g., ``/Host/example.org``. An empty **value** removes existing headers with
|
||||
**name**, e.g., ``/Host/``. The optional **filter-expression** is a mitmproxy
|
||||
[filter expression]({{< relref "concepts-filters">}}) that defines
|
||||
which flows to modify headers on, e.g., only on responses using ``~s``.
|
||||
Existing headers are overwritten by default.
|
||||
This can be changed using filter-expressions, e.g., ``!~h Host:`` to ignore
|
||||
requests and responses with an existing ``Host`` header.
|
||||
|
||||
## Sticky auth
|
||||
|
||||
@ -159,6 +162,7 @@ authentication through the proxy. Note that <span
|
||||
data-role="program">mitmproxy</span> doesn't (yet) support replay of HTTP Digest
|
||||
authentication.
|
||||
|
||||
|
||||
## Sticky cookies
|
||||
|
||||
When the `stickycookie` option is set, **mitmproxy** will add the cookie most
|
||||
@ -176,6 +180,7 @@ replay]({{< relref "#client-side-replay" >}}) - you can record the
|
||||
authentication process once, and simply replay it on startup every time you need
|
||||
to interact with the secured resources.
|
||||
|
||||
|
||||
## Streaming
|
||||
|
||||
By default, mitmproxy will read an entire request/response, perform any
|
||||
@ -196,7 +201,6 @@ their ``.stream`` attribute to ``True``:
|
||||
|
||||
{{< example src="examples/addons/http-stream-simple.py" lang="py" >}}
|
||||
|
||||
|
||||
### Websockets
|
||||
|
||||
The `stream_websockets` option enables an analogous behaviour for websockets.
|
||||
@ -206,6 +210,7 @@ payload sent to the server as the frames are immediately forwarded to the
|
||||
server. In contrast to HTTP streaming, where the body is not stored, the message
|
||||
payload will still be stored in the WebSocket flow.
|
||||
|
||||
|
||||
## Upstream Certificates
|
||||
|
||||
When mitmproxy receives a connection destined for an SSL-protected service, it
|
||||
|
||||
Loading…
Reference in New Issue
Block a user