fix(web): fall back to the PAT when Gitea refuses the login token

The login token took precedence unconditionally, so a configured keyring PAT
could never help while an operator was logged in — and on this instance the
OIDC token (scopes `openid profile`) is exactly what Gitea refuses with a 403
for insufficient API scope. `ExecutionsView` now carries `refused` (401 or a
final 403) and the web layer retries once with the PAT when the token it used
was not already the PAT. A refused PAT is never sent twice, and a 401 still
gets its single refresh attempt first.
This commit is contained in:
2026-07-25 15:07:13 +02:00
parent 4aedd937d7
commit d0ea7f661d
4 changed files with 142 additions and 30 deletions
+5 -4
View File
@@ -304,10 +304,11 @@ automatically; a refusal that refresh cannot fix shows a "log in again" link
in the card.
Optional fallback: store a Gitea PAT in the keyring and name it in
`[web].gitea_token_cred`. It is used only when no logged-in token is
available — after a service restart (which empties the in-process map while
session cookies stay valid), or for an operator whose own token lacks the
scope. Set it exactly like the other secrets:
`[web].gitea_token_cred`. It is used when no logged-in token is available —
after a service restart (which empties the in-process map while session cookies
stay valid) — **and** when Gitea refuses the login token (`401`, or `403` for
insufficient scope), which is what an OIDC token limited to `openid profile`
gets. Set it exactly like the other secrets:
```bash
sudo -u ci-runner /opt/ci/venv/bin/python -m ci_orchestrator creds set \