ActivityWatch / ActivityWatch/aw-server-rust

Extension pairing / code exchange for browser-watcher origins

Offen
#638 0 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Rust
Sterne
315
Forks
96
Ø Merge
2 T. 21 Std.
Gemergte PRs (30 T.)
14

Beschreibung

Follow-up to #637, which narrows the blanket `moz-extension://.*` CORS trust to the three endpoints `aw-watcher-web` needs. That closes the read/exfiltration half of the problem with no client change, but the underlying design issue remains: **any installed Firefox extension can still write into its own bucket**, because extension origins are random per install and cannot be allowlisted up front.

Background and the negative result that makes this necessary are in #637 — briefly: deleting the wildcard does *not* work, because host permissions do not exempt a Firefox background script from CORS (verified in Firefox 152; the server's ACAO header is the sole gate). So consent has to be captured at runtime instead.

## Proposed design

1. Extension `POST`s its origin to `/api/0/pair/request` (reachable under the wildcard).
2. Server mints a short code and surfaces a pending-pairing prompt in aw-webui (same-origin, trusted) and/or the tray.
3. User approves. Server persists `{origin, token}`.
4. Extension polls `/api/0/pair/status`, receives the token, and sends `Authorization: Bearer ` from then on. The server reflects ACAO for that origin only once paired, and enforces the token.

Reuses the existing api_key fairing (`aw-server/src/endpoints/apikey.rs`, #585) rather than adding a second auth path. Ship behind `[auth] require_extension_pairing`, default `false` for one release with a loud warning, then flip.

Needs matching `aw-watcher-web` work, so it is a coordinated change across repos rather than a server-only fix.

## Also outstanding

- **`aw-server` (Python) has the same wildcard** (`aw_server/server.py`, `cors_origins.append("moz-extension://*")`) and needs the endpoint scoping from #637, and later the pairing flow.

## Credit

Original report by pal0x, privately to @ErikBjare, disclosed publicly with @ErikBjare's approval.

Related: #585 (api_key support), #588 / #636 (api_key bypasses), ActivityWatch/activitywatch#1199 (authentication generally).

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.