ActivityWatch / ActivityWatch/aw-server-rust

Extension pairing / code exchange for browser-watcher origins

Abierto
#638 0 comentarios 1 reacción 0 asignados Ver en GitHub
Lenguaje dominante
Rust
Estrellas
315
Forks
96
Merge medio
2 d 21 h
PR fusionados (30 d)
14

Descripción

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).

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.