Grasscutters/mitmproxy
3
0
Fork 0
mirror of https://github.com/Grasscutters/mitmproxy.git synced 2024-11-23 08:11:00 +00:00
Code Issues Projects Releases Wiki Activity

More documentation

Browse Source
This commit is contained in:
Jason A. Novak 2013-04-21 13:36:05 -05:00
parent 52a4a8bbde
commit e951b86c21
1 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc-src/scripting/addingviews.html
View File

@ -10,6 +10,7 @@ By default, mitmproxy has support for displaying the following content types in
- __6__: URL-encoded data - __6__: URL-encoded data
- __7__: XML - __7__: XML
- __8__: AMF (requires PyAMF) - __8__: AMF (requires PyAMF)
- __9__: Protobuf (requires protobuf library)
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: 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:
@ -18,10 +19,11 @@ Each content type invokes a different flow viewer to parse the data and display
## Adding a View class to contentview.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\_\_". 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\_types 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". 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. 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 ODictCaseless object containing the headers of the request/response; content is the content of the request/response, and limit is an integer representing the amount of data to display in the view window.
The \_\_call\_\_ function returns two values: (1) a string describing the parsed data; and (2) the parsed data for friendly display. The parsed data to be displayed should be a list of strings formatted for display. You can use the \_view\_text function in contentview.py to format text for display. Alternatively, you can display content as a series of key-value pairs; to do so, prepare a list of lists, where each list item is a two item list -- a key that describes the data, and then the data itself; after preparing the list of lists, run common.format_keyvals against it to prepare it as text for display.
The \_\_call\_\_ function returns two values: (1) a string describing the parsed data; and (2) the parsed data for friendly display.