Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Store a per-profile API URL for multi-environment auth

Abierto
  • ¿Algo no está bien?
#303 0 comentarios 0 reacciones 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
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
rust
Área
api, authentication, cli

Línea de trabajo

Start with the TokenStore schema and migration paths, then trace read_token, Authentication::new, fetch_profile_info, and fetch_profiles_with_info. Resolve the open URL-capture decision before implementing. Done means profile URLs round-trip, legacy profiles fall back to the global default, and auth list uses each profile's host in tests.

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

Descripción

Background

The multi-profile auth work in #293 stores only a token per profile, and every command resolves the API host from the single API_BASE_URL (defaulting to prod). Since multi-profile usually means multi-environment (for example a prod profile and a stage profile), this means:

  • auth list sends every stored token to the one host, so a stage token gets transmitted to the prod host and then shows blank because it 401s.
  • There is no way to keep a profile pinned to the environment its token belongs to.

Raised by @sergey-borovkov in review: it is much cheaper to decide the storage format now, while it is new, than to migrate it a second time later.

Proposal

Store an optional API URL per profile and use it wherever a profile's token is used (read_token/Authentication::new, fetch_profile_info, fetch_profiles_with_info). Profiles without a URL (including migrated legacy ones) fall back to the current global default, so this stays backward compatible.

Open decision — how is the URL captured?

This is the reason it was deferred from #293 rather than guessed at. Options:

  1. screenly login --url <url> — explicit, but one more flag to pass.
  2. Capture the resolved API_BASE_URL (env or default) at login time and store it — zero new flags, but implicit and easy to get wrong if the env var isn't set.
  3. Both: --url overrides, otherwise capture the resolved base URL.

Option 3 is probably the most forgiving. Worth agreeing on before implementing.

Scope / touch points

  • TokenStore schema: each entry becomes token + optional url (migration-safe, since serde Option defaults to None).
  • Migration: legacy plain-text and existing single-token stores get url: None → global default.
  • read_token / Authentication::new: resolve the active profile's url alongside its token.
  • fetch_profile_info / fetch_profiles_with_info: use the per-profile url.
  • Tests: per-profile url round-trips, fallback to default when absent, auth list hits each profile's own host.

Notes

  • Not a blocker for #293; that PR intentionally leaves this out.
  • Backward compatible if the url field is optional with a default.
Lenguaje dominante
Rust
Estrellas
29
Forks
7
Merge medio
2 d 11 h
PR fusionados (30 d)
9

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 Screenly/cli

Todos los issues de Screenly/cli

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.