Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#303 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
45/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
rust
Lĩnh vực
api, authentication, cli

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Rust
Star
29
Fork
7
Merge trung bình
2 ngày 16 giờ
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Screenly/cli

Tất cả issue của Screenly/cli

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.