I found an issue with editing response body in mitmweb, where I can't get to lines "below" 100. Would this be fixed, or is there any workaround?

macOS X, installed with brew with mitmproxy/mitmdump

The splitter component is currently more of a hack, it'd be nice to fix that properly. It should probably wrap the two subcomponents:

<Splitter>
  <MainView/>
  <EventLog/>
</Splitter>

Mitmproxy recently got a new option management system with a brand new option editor. Needless to say, we should add the same thing to mitmweb. This would bring most of mitmproxy's features to mitmweb, until we find time to develop better UIs for some of them.

I'm opening this ticket to capture a conversation on Slack, before it disappears. I feel that Mitmweb should support an arbitrary command interface, similar to the command execution mode in mitmproxy console. Commands are very powerful, and enable interactions with the proxy that simply weren't possible before without scripting. They're also the primary way for addons to expose operations to users, and addon authors should be confident that the user will be able to invoke those commands whichever tool they're using. In short, they're a major new core component of our project, and I'd like there to be consistency between all our UI tools.

The primary command interface in mitmweb doesn't need to look like the one in console. There, a vim-like text interface is idiomatic. In mitmweb, there's an opportunity to do something more interesting. All arguments and returns are typed, and the type system is going to become more expressive next time I have time to turn to it. This means that you can pick up a command, and build a rich interface for it with file pickers for paths, selectors for options, and with special support for flow and cut selectors. The result might be a command palette, where the user can select a command, and then execute it with a nice set of native controls. That said, we should also retain the ability for a user to just cut-and-paste a full command so they can be shared.

We want an equivalent of pressing o in mitmproxy. In the first iteration, we should expose the important binary options:

• --host
• --no-upstream-cert
• --raw-tcp
• --http2
• --anticache
• --anticomp
• --stickycookie
• --stickyauth
• --stream

There are more, but these are the most important ones IMO.

react-router slows down mitmweb significantly at the moment. Given that we only use it lightly (and it creates more maintenance burden than anything else), we should consider just removing it and doing the little plumbing we have ourselves. It may just be enough to take react-router's underyling history library to parse the URL on start and then unidirectionally push updates later on.

@gzzhanghao, thoughts?

what the title says

We currently use Array.sort in in ducks/utils/store.js, which is a bad idea because it's unstable. We should instead use _.sortBy and adjust makeSort in ducks/flows.js accordingly.

Tests are currently broken. Will get to it tomorrow, if noone picks it up before that.

Turn flow recording on and off via a single button click.

As discussed, we should not throw errors here.

1. WS Connection openend
2. Fetch list
3. Receive delete "foo" event.
4. Receive list. List already does not contain "foo" anymore.
5. Attempt to delete "foo" raises an error.

See comments in mitmproxy/mitmproxy#1267
This issue tracks everything but the splitter.

We have a variety of content views in mitmproxy.contentviews.

1. Users should be able to select any content view (from mitmproxy.contentviews) to display a flow.
2. We also need a few additional content views, e.g. to display images.
3. We need logic to select a content view. Probably it's just if(isImage) /* ... */ else /* let mitmproxy decide */

We need to figure out which parts of the UI we want to test and how we want to test them.

In a nutshell, we don't need it and it just inflates the compiled JS.

Somewhat refs #12 - Having nice timeline or graph visualizations would be nice!

A user should be able to see the certificate details on the details tab, as in mitmproxy (we should re-use code unless there's a really good cert parser in JS)

Users should be able to open existing mitmproxy dumps or save the current session as a mitmproxy dump.

The user should be able to enable/disable server replay mode for all flows in the UI. This is equivalent to pressing “S”, “a” in mitmproxy.

We have 8 different options to configure Server Replay (see Server Replay section mitmproxy --help). We should at least expose the most important ones, i.e. --kill and --no-pop.

depends on #1.

A users should be able to edit flows in an intuitive way. What we currently miss:

1. It is not obvious that you can edit the URL or the header by just clicking on it.
2. We need a good approach for a body editor (see design challenge)
3. Some parts are broken (e.g. editing the HTTP version)

I have started mitmweb as follows
mitmweb --wport=8181

and access the webpage via
http://<ipaddress>:8181

and get 404 Not Found when accessed via proxy.

Console prints following message:
WARNING:tornado.access:404 GET http://stackoverflow.com/

mitmproxy supports multiple proxy modes: http://docs.mitmproxy.org/en/latest/modes.html

This is probably a bit confusing for new users. Ideally, I would like to start in a mode where the local machine is transparently proxied by default, but we have a UI to set up reverse proxies, enable SOCKS mode, etc.

I believe the settings ducks can be flattened to just .settings, not .settings.settings ?

@gzzhanghao, what do you think?

When it comes time to write up Windows documentation, here's some mitmweb start up commands to consider. I placed them in a batch file named wmitm.bat. You don't need to open an elevated cmd window as the first command elevates to administrator runs windows.py and keeps the windows open (/K). The second command invokes the chrome browser and opens the mitmweb UI webpage. The third command invokes mitmweb specifying transparent mode (-T) and to display domain names instead of ip address (--host (not yet implemented in mitmweb)).

powershell.exe -Command start-process -verb runas cmd {/K "C:\Python27\Lib\site-packages\mitmproxy\platform\windows.py"}

start chrome http://localhost:8081

mitmweb -T --host

@gzzhanghao remarked that he is not quite satisfied with the current UI and he would like to simplify the top menu. Here's his very early mockup:

I agree that it's currently a lot of wasted space, but we have lots of stuff to fill it. I'll make a more concrete proposal in the next days and we should meet somewhere in the middle. 😃

Steps to reproduce:

1. Add some flows
2. Take a flow from the middle of the list
3. Update it
4. Flow gets moved to the bottom. :-(

The issue is that https://github.com/mitmproxy/mitmproxy/blob/master/web/src/js/ducks/utils/list.js currently implements updates as remove-then-add. This breaks if no sort function is specified and we rely on natural list ordering.

https://github.com/mitmproxy/mitmproxy/blob/master/web/src/js/ducks/ui/flow.js#L90

When updating flows, the server currently complains about a large list of unknown attributes. We should compare the actual flow with ui.flow.modifiedFlow in stopEdit and create a delta from that to avoid this. Otherwise we risk not seeing errors here.

A user should be able to specify a password that is needed to access the web ui.

We want to rewrite the web ui to use react-redux where possible. Straight from @gzzhanghao's proposal:

• Eliminate react mixins (2 or 3 days)
• Design a set of scalable APIs for further extensions (3 days)
• Eliminate contexts and states with props (1 week)
• Refactor stores and actions with react­redux (1 week)
• Tests for action and reducers (1 week)

We're soon going to have the ability for users to upload a capture to the mitmproxy servers and share it for viewing. To make this scale, I want to be able to host the capture with no server-side support. This means that we'll have an export format that uses summary JSON files and a folder structure that mimics the server-side API of mitmweb, plus a static viewer that can be initialized with a root location. The details here are yet to be finalised - in particular, the static serialization format and upload mechanics are still up in the air - but we need to keep this possibility in mind as we work on the web interface.

A lot of the issues here can be solved by sensibly componentizing things, and making sure that we are mindful of the boundary between active proxy and "viewing only" modes. This will also help the static viewer usecase within mitmweb itself.

It would be awesome if clicking at the cursor position in the screenshot would still focus the textfield.

A user should be able to enable, disable or edit inline scripts in the web UI.

There is anyways to retrieve the mitmdump session if my ssh client got disconnected?

or i have to stop the service a restart?

This should be a single, isolated PR.

Hi. Relative paths is needed for access to mitmweb panel via custom nested url.
Say, https://example.com/some/path/to/mitmweb-panel/
Nginx upstream configuration for example:

upstream mitm  {
  server 127.0.0.1:8081 fail_timeout=0;
}

  location /some/path/to/mitmweb-panel/ {
    # can be protected (basic auth etc.)
    proxy_pass http://mitm/;
    proxy_redirect off;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }

The user should be able to enable client replay. In a first iteration, that may just mean replaying all flows in the view, but ultimately we probably want to be able to select multiple flows and then only replay those.

This should be in the top menu. 😃

We have somewhat working keyboard support. It'd be awesome to fix it up completely, but this is not a blocking feature.

We already have one at https://github.com/mitmproxy/mitmproxy.org/tree/master/logo, which just needs to be included.

There are some features I'd love to see which would indirectly require remote code execution, e.g. a live inline script editor. We may want to do something similar to what Werkzeug does: http://werkzeug.pocoo.org/docs/0.11/debug/, maybe we can even borrow code.

I recently moved a bunch of web projects to Typescript, and the benefits were immediate. We're at a point where ecosystem momentum is coalescing behind Typescript as the "JavaScript+" of choice. It's well-designed, lightweight, clear, and has really, really great developer tool support. We should consider shifting the codebase over.

Users should have a JSFiddle-like thing to visualize the current session (see design challenge).

Filters for request/response body are currently not implemented. This is a tricky feature, as we do not have the bodies in memory on the client side and we kind of need to query the server for this.

Filter parsing is partially broken, possibly due to changes with PEG.js?

From @MatthewShao's proposal:

From Clemens' proposal:

Add a context menu to the list of requests and implement the functionality for (replay+, options, delete, …

I personally think this is not a bad thing to have, but all features should be accessible outside of the context menu as well. Not our primary use-case, but you cannot right-click on a tablet.