Server auth: API tokens for non-browser clients (Home Assistant, scripts)

Abierto
  • ¿Algo no está bien?
#763 1 comentario 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
api, authentication, cli, security

Línea de trabajo

Start by reading the server authentication middleware, the users-file watcher, and revoked.rs to understand how sessions and role changes are handled. Then trace the cook server user command to see where token add, list, and revoke commands would fit. Done means hashed tokens authenticate API requests as their user, revocation takes effect on the next request, and /api-docs explains the flow.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

Once a users file exists, every write needs a signed-in session — and the only way to get one is the browser login form (HttpOnly session cookie). Non-browser clients have no way to authenticate, so on a server with sign-in enabled they're read-only:

  • homeassistant-cookcli — add_recipe_to_shopping_list, clear_shopping_list, removing recipes, and ticking ingredients off (/api/shopping_list/add|remove|clear|check|uncheck) all get 401. Reads and POST /api/shopping_list still work since they're open.
  • curl / cron / shell scripts against the API.

Users who self-host behind a NAS or reverse proxy are exactly the ones who turn sign-in on and want home automation.

Proposal

Bearer tokens tied to a user, so they inherit that user's role (Reader / Shopper / Editor / Admin) and the existing middleware capability checks apply unchanged:

cook server token add <user> [--name home-assistant]   # prints the token once
cook server token list
cook server token revoke <name>
  • Request: Authorization: Bearer <token>; the middleware resolves it to a Viewer the same way it does a session cookie.
  • Store only a hash next to the users file; picked up by the existing watcher, revocation applies on the next request (like role changes and revoked.rs).
  • A token never sets a cookie, so it doesn't widen the browser's CSRF surface.
  • Typical setup: cook server user add ha --role shopper + a token for it — least privilege for automations.
  • Document in /api-docs.

Then

homeassistant-cookcli adds an optional token field to its config flow and sends the header.

Lenguaje dominante
Rust
Estrellas
1.4k
Forks
120
Merge medio
1 d 20 h
PR fusionados (30 d)
116

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cooklang/cookcli

Todos los issues de cooklang/cookcli

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.