ProtonVPN auto-update cannot re-authenticate from the stored auth file

mysticalsoap commented

2026-08-24 13:38:40 -04:00

Owner

Follow-up to #33 / #146.

The scheduled auto-update path (import_thread with credentials == "unknown") re-reads <provider>-auth.txt and feeds that pair back into the import. Since #146 the auth file deliberately holds the OpenVPN credentials fetched from /vpn, which cannot pass SRP — so a ProtonVPN auto-update fails with the misleading "perhaps the credentials you entered are wrong" popup. Manual update from the GUI is unaffected (the user re-enters account credentials). 2FA accounts have the same problem even if account credentials were stored: no fresh TOTP is available at auto-update time.

Likely shape of a fix: persist the proton-core session (refresh token) at import time — root-owned 0600 next to the certs — and have the provider try session.refresh() before falling back to SRP with whatever credentials it was handed. Avoids storing the account password at all.

🤖 Generated with Claude Code

Follow-up to #33 / #146. The scheduled auto-update path (`import_thread` with `credentials == "unknown"`) re-reads `<provider>-auth.txt` and feeds that pair back into the import. Since #146 the auth file deliberately holds the *OpenVPN* credentials fetched from `/vpn`, which cannot pass SRP — so a ProtonVPN auto-update fails with the misleading "perhaps the credentials you entered are wrong" popup. Manual update from the GUI is unaffected (the user re-enters account credentials). 2FA accounts have the same problem even if account credentials were stored: no fresh TOTP is available at auto-update time. Likely shape of a fix: persist the proton-core session (refresh token) at import time — root-owned 0600 next to the certs — and have the provider try `session.refresh()` before falling back to SRP with whatever credentials it was handed. Avoids storing the account password at all. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

mysticalsoap added the

ux

bug

labels

2026-08-24 13:38:40 -04:00

mysticalsoap commented

2026-08-24 15:04:29 -04:00

Author

Owner

The CAPTCHA gate (#150) makes this worse than first filed: scheduled auto-update for ProtonVPN is now triple-blocked — stored creds are the OpenVPN pair (can't SRP), every fresh login draws a CAPTCHA no scheduler can solve, and 2FA accounts would need a fresh TOTP. All three dissolve with the same fix sketched here: persist the proton-core session (UID/AccessToken/RefreshToken, root-owned 0600) after a successful interactive import, and have update runs call session.refresh() instead of logging in — no password, no CAPTCHA, no TOTP. When the refresh token has been invalidated, fail with 'run the import interactively once' rather than the misleading wrong-credentials message. This is now the prerequisite for auto-update ever working with Proton, not just a nice-to-have.

mysticalsoap referenced this issue

2026-08-24 15:13:05 -04:00

ProtonVPN WireGuard support #152

~~mysticalsoap referenced this issue 2026-08-24 15:58:58 -04:00~~

add: auto-open Proton's verification page in the gui's browser #154

mysticalsoap referenced this issue

2026-08-24 16:24:47 -04:00

ProtonVPN import: support Proton's human-verification (CAPTCHA) flow #150

mysticalsoap referenced this issue from a commit

2026-08-24 16:52:21 -04:00

fix: resume ProtonVPN updates from a persisted session, not SRP

mysticalsoap referenced this issue from a pull request that will close it,