Give the six provider implementations shared structure #23

New issue

Closed

opened 2026-08-17 16:57:01 -04:00 by mysticalsoap · 1 comment

mysticalsoap commented

2026-08-17 16:57:01 -04:00

Owner

airvpn, mullvad, pia, windscribe, protonvpn and azirevpn in
update.py duplicate one skeleton: allow-list IPs, fetch, parse into
{server, protocol, provider}, copy_certs, finished.emit.

The duplication causes real drift -- inconsistent error handling across the six,
and the conf.ROOTDIR typo that has never run.

A Provider base class with a template run() and per-provider fetch/parse
hooks is the right structure, and it is what makes SRP tractable: it becomes an
auth strategy on one provider rather than a special case inside a 100-line
method.

Do this after provider parsing has test coverage. These methods encode
undocumented API knowledge (AirVPN's RSA+AES handshake, Windscribe's CSRF login,
Mullvad's scraped table) that is the reason to keep this code at all.
Refactoring it blind is how that gets lost.

`airvpn`, `mullvad`, `pia`, `windscribe`, `protonvpn` and `azirevpn` in `update.py` duplicate one skeleton: allow-list IPs, fetch, parse into `{server, protocol, provider}`, `copy_certs`, `finished.emit`. The duplication causes real drift -- inconsistent error handling across the six, and the `conf.ROOTDIR` typo that has never run. A `Provider` base class with a template `run()` and per-provider `fetch`/`parse` hooks is the right structure, and it is what makes SRP tractable: it becomes an auth strategy on one provider rather than a special case inside a 100-line method. **Do this after provider parsing has test coverage.** These methods encode undocumented API knowledge (AirVPN's RSA+AES handshake, Windscribe's CSRF login, Mullvad's scraped table) that is the reason to keep this code at all. Refactoring it blind is how that gets lost.

mysticalsoap added the

architecture

label

2026-08-17 16:57:01 -04:00

mysticalsoap commented

2026-08-20 18:55:14 -04:00

Author

Owner

Provider-page design decisions from the 2026-08-20 import discussion (see #74), recorded here since the data model would land with this refactor:

An entry is (display name, provider type, credentials, server list) — name ≠ type. Custom entries already work this way (typed name + custom type); supported providers conflate name and type everywhere (SUPPORTED_PROVIDERS membership checks, per-provider update routines, credential-store paths). This refactor is the moment that split becomes cheap; retrofitting it later is not.
The provider page gets two sections: an inventory of configured entries first (per-entry update/delete; custom entries list their servers, not files — internal storage stays a non-concept in the UI), then a separate add flow (type dropdown + name field, name defaulting to the type).
Name collision in the add flow redirects to the update flow for the existing entry — append-vs-replace becomes the update screen's concern, not an import-time policy.
Multiple accounts of one type (e.g. two Proton accounts to dodge per-account session limits) = multiple entries of that type. The schema supports it from the start; the UI affordance stays unbuilt until something wants it. 0.9.2's Proton hookup ships one-entry-per-type.

Import mechanics (multi-file picker replacing directory semantics) land independently via #74.

Provider-page design decisions from the 2026-08-20 import discussion (see #74), recorded here since the data model would land with this refactor: - An entry is **(display name, provider type, credentials, server list)** — name ≠ type. Custom entries already work this way (typed name + custom type); supported providers conflate name and type everywhere (`SUPPORTED_PROVIDERS` membership checks, per-provider update routines, credential-store paths). This refactor is the moment that split becomes cheap; retrofitting it later is not. - The provider page gets two sections: an **inventory** of configured entries first (per-entry update/delete; custom entries list their *servers*, not files — internal storage stays a non-concept in the UI), then a separate **add flow** (type dropdown + name field, name defaulting to the type). - Name collision in the add flow redirects to the update flow for the existing entry — append-vs-replace becomes the update screen's concern, not an import-time policy. - Multiple accounts of one type (e.g. two Proton accounts to dodge per-account session limits) = multiple entries of that type. The schema supports it from the start; the UI affordance stays unbuilt until something wants it. 0.9.2's Proton hookup ships one-entry-per-type. Import mechanics (multi-file picker replacing directory semantics) land independently via #74.

mysticalsoap referenced this issue

2026-08-23 01:45:11 -04:00

Module decomposition (index) #83

mysticalsoap referenced this issue

2026-08-23 01:45:32 -04:00

Module decomposition (index) #83

mysticalsoap referenced this issue

2026-08-24 00:03:33 -04:00

Drop PIA and AzireVPN from the supported providers #134

mysticalsoap referenced this issue from a commit

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

add: characterization tests for the four kept provider imports