diff options
Diffstat (limited to 'docs/dev')
| -rw-r--r-- | docs/dev/addingviews.html | 52 | ||||
| -rw-r--r-- | docs/dev/architecture.rst | 14 | ||||
| -rw-r--r-- | docs/dev/exceptions.rst | 9 | ||||
| -rw-r--r-- | docs/dev/models.rst | 59 | ||||
| -rw-r--r-- | docs/dev/protocols.rst | 15 | ||||
| -rw-r--r-- | docs/dev/proxy.rst | 12 | ||||
| -rw-r--r-- | docs/dev/sslkeylogfile.rst | 14 | ||||
| -rw-r--r-- | docs/dev/testing.rst | 47 |
8 files changed, 222 insertions, 0 deletions
diff --git a/docs/dev/addingviews.html b/docs/dev/addingviews.html new file mode 100644 index 00000000..12623a31 --- /dev/null +++ b/docs/dev/addingviews.html @@ -0,0 +1,52 @@ +As discussed in [the Flow View section of the mitmproxy +overview](@!urlTo("mitmproxy.html")!@), mitmproxy 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. + +Each content type invokes a different flow viewer to parse the data and display +the friendly view. Users can add custom content viewers by adding a view class +to contentview.py, discussed below. + +## Adding a new View class to contentview.py + +The content 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 a new content viewer to parse a data type is as simple as writing a new +View class. Your new content viewer View class should have the same properties +as the other View classes: __name__, __prompt__, and __content\_types__ and a +__\_\_call\_\___ function to parse the content of the request/response. + +* The __name__ property should be a string describing the contents and new content viewer; +* The __prompt__ property should be a two item tuple: + + - __1__: A string that will be used to display the new content viewer's type; and + - __2__: A one character string that will be the hotkey used to select the new content viewer from the Flow View screen; + +* The __content\_types__ property should be a list of strings of HTTP Content\-Types that the new content viewer 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\_types__ 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, use the __common.format\_keyvals__ function on it to prepare it as text +for display. + +If the new content viewer fails or throws an exception, mitmproxy will default +to a __raw__ view. diff --git a/docs/dev/architecture.rst b/docs/dev/architecture.rst new file mode 100644 index 00000000..e7995141 --- /dev/null +++ b/docs/dev/architecture.rst @@ -0,0 +1,14 @@ +.. _architecture: + +Architecture +============ + +To give you a better understanding of how mitmproxy works, mitmproxy's +high-level architecture is detailed in the following graphic: + +.. image:: ../schematics/architecture.png + +:download:`architecture.pdf <../schematics/architecture.pdf>` + +Please don't refrain from asking any further +questions on the mailing list, the Slack channel or the GitHub issue tracker. diff --git a/docs/dev/exceptions.rst b/docs/dev/exceptions.rst new file mode 100644 index 00000000..e890476b --- /dev/null +++ b/docs/dev/exceptions.rst @@ -0,0 +1,9 @@ +.. _exceptions: + +Exceptions +========== + +.. automodule:: mitmproxy.exceptions + :show-inheritance: + :members: + :undoc-members: diff --git a/docs/dev/models.rst b/docs/dev/models.rst new file mode 100644 index 00000000..7a949941 --- /dev/null +++ b/docs/dev/models.rst @@ -0,0 +1,59 @@ +.. _models: + +Models +====== + +.. automodule:: netlib.http + + .. autoclass:: Request + + .. rubric:: Data + .. autoattribute:: first_line_format + .. autoattribute:: method + .. autoattribute:: scheme + .. autoattribute:: host + .. autoattribute:: port + .. autoattribute:: path + .. autoattribute:: http_version + .. autoattribute:: headers + .. autoattribute:: content + .. autoattribute:: timestamp_start + .. autoattribute:: timestamp_end + .. rubric:: Computed Properties and Convenience Methods + .. autoattribute:: text + .. autoattribute:: url + .. autoattribute:: pretty_host + .. autoattribute:: pretty_url + .. autoattribute:: query + .. autoattribute:: cookies + .. autoattribute:: path_components + .. automethod:: anticache + .. automethod:: anticomp + .. automethod:: constrain_encoding + .. autoattribute:: urlencoded_form + .. autoattribute:: multipart_form + + .. autoclass:: Response + + .. rubric:: Data + .. autoattribute:: http_version + .. autoattribute:: status_code + .. autoattribute:: reason + .. autoattribute:: headers + .. autoattribute:: content + .. autoattribute:: timestamp_start + .. autoattribute:: timestamp_end + .. rubric:: Computed Properties and Convenience Methods + .. autoattribute:: text + .. autoattribute:: cookies + + .. autoclass:: Headers + :members: + :special-members: + :no-undoc-members: + + .. autoclass:: decoded + +.. automodule:: mitmproxy.models + :show-inheritance: + :members: HTTPFlow, Error, ClientConnection, ServerConnection
\ No newline at end of file diff --git a/docs/dev/protocols.rst b/docs/dev/protocols.rst new file mode 100644 index 00000000..ceb5c2fd --- /dev/null +++ b/docs/dev/protocols.rst @@ -0,0 +1,15 @@ +.. _protocols: + +Protocols +========= + +.. automodule:: mitmproxy.protocol + + .. autoclass:: Layer + :members: + :special-members: + + .. autoclass:: ServerConnectionMixin + :members: + + .. autoexception:: Kill diff --git a/docs/dev/proxy.rst b/docs/dev/proxy.rst new file mode 100644 index 00000000..888fb946 --- /dev/null +++ b/docs/dev/proxy.rst @@ -0,0 +1,12 @@ +.. _proxy: + +Proxy Server +============ + +.. automodule:: mitmproxy.proxy + + .. autoclass:: ProxyServer + .. autoclass:: DummyServer + .. autoclass:: ProxyConfig + .. autoclass:: RootContext + :members: diff --git a/docs/dev/sslkeylogfile.rst b/docs/dev/sslkeylogfile.rst new file mode 100644 index 00000000..04b86cc4 --- /dev/null +++ b/docs/dev/sslkeylogfile.rst @@ -0,0 +1,14 @@ +.. _sslkeylogfile: + +TLS Master Secrets +================== + +The SSL master keys can be logged by mitmproxy so that external programs can decrypt TLS +connections both from and to the proxy. Key logging is enabled by setting the environment variable +:envvar:`SSLKEYLOGFILE` so that it points to a writable text file. +Recent versions of WireShark can use these log files to decrypt packets. +You can specify the key file path in WireShark via +:samp:`Edit -> Preferences -> Protocols -> SSL -> (Pre)-Master-Secret log filename`. + +Note that :envvar:`SSLKEYLOGFILE` is respected by other programs as well, e.g. Firefox and Chrome. +If this creates any issues, you can set :envvar:`MITMPROXY_SSLKEYLOGFILE` alternatively. diff --git a/docs/dev/testing.rst b/docs/dev/testing.rst new file mode 100644 index 00000000..e3b86bf3 --- /dev/null +++ b/docs/dev/testing.rst @@ -0,0 +1,47 @@ +.. _testing: + +Testing +======= + +All the mitmproxy projects strive to maintain 100% code coverage. In general, +patches and pull requests will be declined unless they're accompanied by a +suitable extension to the test suite. + +Our tests are written for the `py.test`_ or nose_ test frameworks. +At the point where you send your pull request, a command like this: + +>>> py.test -n 4 --cov mitmproxy + +Should give output something like this: + +.. code-block:: none + + > ---------- coverage: platform darwin, python 2.7.2-final-0 -- + > Name Stmts Miss Cover Missing + > ---------------------------------------------------- + > mitmproxy/__init__ 0 0 100% + > mitmproxy/app 4 0 100% + > mitmproxy/cmdline 100 0 100% + > mitmproxy/controller 69 0 100% + > mitmproxy/dump 150 0 100% + > mitmproxy/encoding 39 0 100% + > mitmproxy/filt 201 0 100% + > mitmproxy/flow 891 0 100% + > mitmproxy/proxy 427 0 100% + > mitmproxy/script 27 0 100% + > mitmproxy/utils 133 0 100% + > mitmproxy/version 4 0 100% + > ---------------------------------------------------- + > TOTAL 2045 0 100% + > ---------------------------------------------------- + > Ran 251 tests in 11.864s + + +There are exceptions to the coverage requirement - for instance, much of the +console interface code can't sensibly be unit tested. These portions are +excluded from coverage analysis either in the **.coveragerc** file, or using +**#pragma no-cover** directives. To keep our coverage analysis relevant, we use +these measures as sparingly as possible. + +.. _nose: https://nose.readthedocs.org/en/latest/ +.. _py.test: https://pytest.org/ |