diff options
Diffstat (limited to 'doc-src/scripting/addingviews.html')
| -rw-r--r-- | doc-src/scripting/addingviews.html | 27 |
1 files changed, 27 insertions, 0 deletions
diff --git a/doc-src/scripting/addingviews.html b/doc-src/scripting/addingviews.html new file mode 100644 index 00000000..34c59a91 --- /dev/null +++ b/doc-src/scripting/addingviews.html @@ -0,0 +1,27 @@ +As discussed in [the Flow View section of the mitmproxy overview](@!urlTo("mitmproxy.html")!@) allows you to inspect and manipulate flows. When inspecting a single flow, mitmproxy uses a number of heuristics to show a friendly view of various content types; if mitmproxy cannot show a friendly view, mitmproxy defaults to a __raw__ view. + +By default, mitmproxy has support for displaying the following content types in a friendly view: + +- __1__: Hex +- __2__: HTML +- __3__: Image +- __4__: JavaScript +- __5__: JSON +- __6__: URL-encoded data +- __7__: XML +- __8__: AMF (requires PyAMF) + +Each content type invokes a different flow viewer to parse the data and display the friendly view. Users can add support for custom views by: + +- __1__: Adding a new View class to contentview.py; and +- __2__: Adding the hotkey to new view to flowview.py + +## Adding a View class to contentview.py + +The viewers used by mitmproxy to present a friendly view of various content types are stored in contentview.py. Reviewing this file shows a number of classes named ViewSomeDataType, each with the properties: name, prompt, and content-type and a function named "\_\_call\_\_". + +Adding code to parse additional data types is as simple as writing a new View class. It should have the same properties and function as the other View classes. The name property should be a string describing the contents and view; the prompt property should be a two item tuple where the first item is a string that will be used to display the View's type and the second item is a one character string that will be the hotkey used to select the view; the content-type property should be a list of strings of content\_types that the view can parse. Note that mitmproxy will use the content\_types to try and heuristically show a friendly view of content and that you can override the built-in views by populating content\_types with values for content\_types that are already parsed -- e.g. "image/png". + +After defining the name, prompt, and content\_type properties of the class, you should write the \_\_call\_\_ function, which will parse the request/response data and provide a friendly view of the data. The \_\_call\_\_ function should take the following arguments: self, hdrs, content, limit; hdrs is a ODict of the headers of the request/response; content is the content of the request/response, and limit is XXXXX. + +The \_\_call\_\_ function returns two values: (1) a string describing the parsed data; and (2) the parsed data for friendly display. |