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

Open
#303 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
rust

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
Rust
Stars
29
Forks
7
Avg merge
1d 20h
Merged PRs (30d)
12

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Screenly/cli

All issues in Screenly/cli

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.