A self-hosted Gitea answers 401 to `Authorization: token <password>` and
200 to the same value as `user:password`, and the account store's
`secret_kind` cannot tell the two apart — it is a label the human typed
at `identity_save`, so a login password saved as a token is
indistinguishable from a real PAT until the forge answers.
`GiteaForge` had one auth path: the token header, on every call. A
watch whose credential resolved to a password therefore 401'd on every
poll, forever, while the same secret worked for `git push` over https
(the credential helper sends it as a password). The watch looked quiet
instead of broken.
`GiteaForge::with_login` names the login that owns the secret, and
`send` tries the token header first, then — on a 401 only — the same
value as Basic auth. The retry is cloned before the token header lands,
so the fallback request carries one `Authorization` header and not two.
No login (a pasted watch token names none) or an unclonable body leaves
the 401 to surface exactly as it did before.
The login reaches the client in the next commit; this one is the adapter
half, tested against a mock that refuses the token header and accepts
the Basic one.
The watch key encoded source, repo, and number but not the thread
kind, and on GitLab an issue and a merge request share one number
space: iid 7 twice produced one key, one snapshot, and comments on
the merge request landing in the issue (or a 404 fallback that
misrouted the other way). The key carries the kind now —
{source}:{kind}:{owner}/{name}#{number}, with GitLab spelling the
pull variant mr — comment and snapshot route outright by kind, and a
kind-less payload parses to the unparsable key instead of guessing
issue. The claw's callers thread the kind from the payload and strip
the segment where the bare repo is wanted; pre-kind stored keys parse
as None rather than misroute. Four route-pinning wiremock tests cover
the GitLab split, and the GitHub/Gitea clients take the kind without
using it (their issues and PRs share the same REST space).
The stored `colors` key names a palette — rhema (the default,
Jadeite), aquamarine, black-and-white, or dracula — and the
Appearance page of /settings cycles it live, like the theme and
icon toggles beside it. Each palette carries a dark and a light
appearance under the existing `theme` key; dracula's light side is
derived, the official palette ships only dark.
The appearance decision moves off token comparison: Theme now
answers is_dark() from the ground/text luminance, so palettes
beyond the original two get the right per-profile fallback tones.
kosmos
vhaudiquet