tuist auth whoami reports “You are not logged in” when a project or account token is in effect

Summary

tuist auth whoami prints “You are not logged in. Run ‘tuist auth login’.” whenever the resolved credential is a project token or an account token — even though the CLI is fully authenticated and every other command works against the server.

This is actively misleading. It reads as “no credential”, when the truth is “a credential that isn’t a user session”.

Reproduction

Authenticate the CLI with any non-user credential — e.g. set TUIST_TOKEN, or have an account-type token in ~/.config/tuist/credentials/<host>.json — then:

$ tuist auth whoami
You are not logged in. Run 'tuist auth login'.

$ tuist generate      # succeeds, and uploads an authenticated run

Mechanism

ServerSessionController.whoami(serverURL:) returns nil for anything that isn’t .user:

switch token {
case let .user(accessToken: accessToken, refreshToken: _):
    return accessToken.preferredUsername
case .project, .account:
    return nil
}

authenticatedHandle(serverURL:) then throws ServerSessionControllerError.unauthenticated, whose message is the “not logged in” string. It also throws for a .user token whose preferredUsername claim is absent.

The information is often right there in the token: an account token minted by the OAuth flow carries preferred_username and user_id claims, and JWT already decodes preferredUsername. whoami discards it.

Impact

This makes real problems very hard to diagnose. A developer whose CLI holds an account token sees “not logged in” while their runs are being uploaded and attributed to nobody — the two symptoms look like an authentication bypass rather than one credential-kind mismatch. It cost a full investigation to establish that the CLI was authenticated the whole time.

Proposed behaviour

whoami should report the credential that is actually in effect rather than claiming there is none:

• account token carrying preferred_username → name the user, and say the session came from an account token
• account or project token without a usable identity claim → say which kind of credential is in effect and where it was resolved from (which environment variable, or the credentials file)
• genuinely no credential → the current message

Reporting the resolution source matters as much as the identity: ServerAuthenticationController.authenticationToken checks TUIST_TOKEN, then TUIST_CONFIG_TOKEN, then TUIST_CONFIG_CLOUD_TOKEN before the credentials store, so an environment variable silently wins over an interactive login and there is currently no way to see that from the CLI.

Related

The attribution consequence on the server is filed as #12218.

No GitHub comments yet.