Two live-confirmed 403 responses (not source reading, which had already
given one wrong answer) showed /user/starred/{owner}/{repo} requires
BOTH scopes at once: requesting write:repository alone got
required=[write:user]; requesting write:user alone then got
required=[write:repository]. Both are now requested.
Added debug-build-only HTTP status/body logging (HttpTransport
.requireSuccess) and toggleFavorite failure logging, which is how this
was actually diagnosed -- ground truth from the server beats re-reading
Go route source through a summarizing tool. Required testOptions {
unitTests { isReturnDefaultValues = true } } in build.gradle.kts so
those Log calls don't throw inside plain JVM unit tests.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Traced the live 'denied:server_error' login failure to Gitea 1.23.5's
own GrantApplicationOAuth: it refuses to silently widen an existing
OAuth2 grant's scope (grant.Scope != form.Scope -> ErrorCodeServerError,
'a grant exists with different scope'). No code change -- this is
Gitea's own intended behavior. Fix is to revoke UBGitea's existing
authorization from Gitea's Settings > Applications page before retrying
login, so a fresh grant is created under the new scope.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Gitea's PUT/DELETE /user/starred/{owner}/{repo} require write:repository
token scope (verified against Gitea's route registration source), but
this app's OAuthClientConfig only ever requested read-only scopes,
enforced by a hard require() -- every star/unstar attempt was guaranteed
to fail server-side (403), surfaced as the reported red 'failed' star.
Adds write:repository as one narrow, explicit exception to the read-only
invariant (every other write scope, including the pre-existing unused
write:user, is still rejected). Requires one manual re-login on already
logged-in devices before it takes effect, since a refresh token carries
forward the scope it was originally granted under.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
