-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to stop intercepting a source #598
Comments
A source as in an domain or an specific url from an domain? and if an domain you already can in settings but i think that only works if you pay for pro. Or is it like an button on the view page on any request/response that you want that would like temporary or permanently block the domain essentially adding it to the TLS Passthrough? |
@nutterthanos a source as in any of the options in the intercept tab; chrome, global chrome, attach to jvm, android device via adb, etc.. I believe having a disconnect button from the intercept tab connected sources itself will be helpful in disconnecting one or more sources from the HTTP Toolkit app itself. |
I'm also interested in this, I usually intercept a container or existing terminal to debug something and when I'm done I close HTTP toolkit resulting in all following network calls from that container/terminal failing due to the proxy being stopped. Would be great if there was an easy way to stop the interception without having to restart the container or terminal. |
Interesting! Yes, it's a good suggestion. Right now some of the functionality for this already exists, but it's only used during shutdown: when you close an HTTP Toolkit window, it will try to stop intercepted browsers, disconnect Android devices, shutdown Docker containers etc (because all of them will become unusable without the proxy running). It's not always possible though - e.g. for existing terminals we don't actually have control of the process because it was a terminal started elsewhere, so there's not much we can do (ideas welcome if you have a good way to handle this though). Currently that's always on a proxy-port basis - e.g. "shutdown all Docker containers dependent on proxy port 8000", but it could be extended to individual targets in most cases. To see how that works, take a look at the I'd be interested in supporting this more properly. To do so we'd need to:
Note that 'Connected Sources' is currently a bit simplistic and wouldn't neatly line up with this: it just groups sources by user agent info in most cases, which means you might see multiple lines for the same thing (one Docker container making requests with both Ruby & Python with be two sources) or only one line for many things (multiple terminals sending with curl will appear as one curl source). We could change that though if the server exposed info about deactiveable targets, or we could make a separate UI elsewhere (e.g. stop buttons within the Docker container selector list). UX ideas very welcome and PRs towards the above very welcome! I'm not going to be able to start working on this myself in the short term, but feel free to investigate any of the above and ask questions here or open PRs if you're interested (note that Pro is free for all contributors). As a short-term workaround in the meantime, you can probably do this by using multiple sessions: open a separate HTTP Toolkit for each thing you want to intercept, intercept via that window and then close the window (which should try to shut down the source) when you're done. Each window takes a different port and they can all intercept independently in parallel. It's not perfect UX and it's not very discoverable, but that might work for some cases. |
When intercepting an exiting terminal, we can copy a command that runs a script to do the intercept. |
essentially all it does is add only to said terminal is some environment variables technically you could easily make an script that does that or if anyone here knew then an button in their own local copy of httptoolkit from its source code in the ui/backend or whatever |
This is a good idea actually, and I think it's fairly easy to do, without even needing to copy another command. The terminal setup scripts that power this for Bash/Fish/Powershell existing terminals are here. The copied command just pulls the appropriate script and runs it in the terminal. We could:
Does that make sense? I'd be happy to include this, PRs welcome. While it would be nice to do all three shells, it's not strictly required to do the same for all 3, so PRs for any one of these individually would be fine. |
That absolutely makes sense - I'll take a look at the code and try to find the time for a PR. |
The awesome @xKiian has now very helpfully implemented this for existing terminal powershell interception, in httptoolkit/httptoolkit-server#125! That will be live in the next server release, coming soon. PRs for other terminal options (or any other targets) very welcome 😄 |
i would include having it for domains too |
@nutterthanos how would that work? HTTP Toolkit intercepts all traffic from a client, regardless of domain. Do you just want to filter out traffic for some domains? You can do that easily with Alternatively, it is possible to do this for TLS traffic using TLS passthrough in the Pro settings, where the traffic to a given hostname is tunnelled blindly (without TLS interception) but that only works for TLS traffic which includes an SNI (common, but plain HTTP & non-SNI traffic is also not especially unusual). |
i meant by essentially tls passthrough/recording passthrough like an include/exclude filter which can include wildcards like * which is different to filtering the current results on the page otherwise there is this #614 |
There should be a way to stop/disconnect intercepting a source on-demand.
For example, I usually need to intercept multiple sources, then later stop needing to intercept one source or another. I have not found any way to stop interception other than closing the source itself, which is often inconvenient.
Please forgive me if this has already been answered, I have searched in the docs & issues, but not yet found anything related.
Does this affect you too? Click below and add a 👍 to vote for this and help decide where HTTP Toolkit goes next, or go vote on the other most popular ideas so far.
The text was updated successfully, but these errors were encountered: