Skip to content

Multi-token registry auth: support a read-write token, not only write-only #81

Description

@hoangvuanduin

Summary

In the self-hosted registry's multiple-token authentication mode, the two tokens are read-only (READ_ACCESS_TOKEN) and write-only (WRITE_ACCESS_TOKEN) — the write token authorizes write requests only and is rejected on reads. I'd like to request that the split be read-only + read-write (the write token, or an additional token, also grants read) rather than read-only + write-only.

Motivation

Our consumers fall into two access modes: read-only, and read + write. The current design makes the read+write mode painful:

  • Re-auth on every mode switch. The pesde CLI holds one token per index (pesde auth login -t <token>). A single workflow that both reads (resolve/install dependencies) and writes (publish) can't use one credential — the write token 401s on the read step and the read token can't publish — so we have to re-authenticate every time we switch between a read and a write action in the same pipeline.
  • Full access is all-or-nothing. The single-token ACCESS_TOKEN mode does grant read+write, but adopting it means we lose the ability to also hand out a read-only-restricted token to read-only consumers. We want both: a restricted read-only token and a full read+write token.
  • Write-only is rarely useful on its own. Publishing and CI almost always need to read as well (resolving/downloading dependencies, verifying state). A token that can write but not read doesn't fit most real workflows.

Proposal

In multi-token mode, make the write token grant read + write (or add a distinct read-write token), so the two modes become read-only and read-write. This keeps the read-only restriction for consumers who should have it, while letting a single credential drive a read-then-write workflow without re-auth juggling.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions