diff options
| author | srdusr <[email protected]> | 2026-06-29 09:58:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2026-06-29 09:58:00 +0200 |
| commit | 2ade8c807584bff0b60d6b6f278dbde29b13a5ff (patch) | |
| tree | 4de78c2face8f9c85f2fe4c5db2fb6ba9d4540eb /internal/store/store.go | |
| parent | e01afcbf0de00af52fe90959ba77288679e3303d (diff) | |
| download | mitmux-2ade8c807584bff0b60d6b6f278dbde29b13a5ff.tar.gz mitmux-2ade8c807584bff0b60d6b6f278dbde29b13a5ff.zip | |
Browser-launcher helper: throwaway proxied profile, one flag
Adds -launch-browser=chrome|firefox|auto to the mitmux TUI binary.
Resolves an installed browser (PATH first, then common per-OS install
locations), spins up a brand new throwaway profile, configures it to
proxy through the daemon, and opens straight to http://mitmux.cert/ so
installing the CA in that profile is one click.
This is the answer to "build an in-house browser": a bundled GUI
browser is a different, much larger project and works against this
tool's terminal-native positioning - the actually useful part of that
idea is zero-friction setup (proxy + CA-install page, no profile
pollution), which this delivers by launching the user's own browser
in a disposable profile instead of embedding one.
Chrome takes --proxy-server as a flag; Firefox has none, so its
profile gets a generated user.js instead - the only non-interactive
way to configure it. Verified against this machine's real installed
Chrome and Firefox: binary discovery resolves both, auto prefers
chrome-family when both are present, and the generated Firefox prefs
are well-formed. Deliberately did not spawn a live browser window as
part of verification - that's a visible GUI action on whoever runs
it, left for a user to trigger by hand via the flag.
Diffstat (limited to 'internal/store/store.go')
0 files changed, 0 insertions, 0 deletions