Fix issues with authenticating to private-API servers.
Review Request #14751 — Created Jan. 7, 2026 and updated — Latest diff uploaded
Review Board's API has certain resources that require authentication.
But some resources like its root resource, the session resource, and
the server resource don't require any. However, there's a server
setting that lets you disable anonymous read access to the API. When
that is set, every request to the API must be authenticated.RBTools assumes that the public API resources would always be public. We
weren't properly handling communication with private-API servers. This
has revealed itself in a few issues:
Web-based login caused a regression. When a command that requires the
API first initializes itself, it creates an API client and fetches the
root resource. That fetch triggers our auth handlers to prompt for
authentication, but the web login handler would break because its
callback expects the root resource and API client to already be set.
This regression was never made public, it comes from recent
work that hasn't been released yet.If a user is logged out and does
rbt logout, they'll be prompted to
login again.If a user is logged out and does
rbt login, they'll successfully
login but we'll print the "You're already logged in" message.This change addresses those issues and makes sure that we properly
authenticate commands when interacting with private-API servers. We add
ahas_session_cookie()method to the API client (and all the way down
to the server class) which returns whether we have a local session
cookie for the server. This information helps us deal with issues 2 and
3. We also update the login/logout commands to needs_api=False to
address issues 2 and 3.The web login handler no longer assumes that a root resource is set. We
need the root to get the server info, in order to see whether web login
is supported on the server or not. In the case where we're working with a
private-API server while logged out, we'll just assume that the server
supports web login. Even if it doesn't, the auth will fail and we'll
move on to the username/password prompt handler.
- Ran unit tests.
- Tested login/logout on both private-API servers and public ones.
- Tested login with api tokens, username/password, and web login.