Problem
An inactive or unconfirmed account is currently difficult to distinguish from an account with invalid credentials.
Observed with Gramps Web API 3.19.0:
POST /api/users/{user_name}/register/
→ 201 Created
→ account remains unconfirmed
POST /api/token/
→ 403
→ "Invalid username or password"
The second response hides the actual account state.
Request
Please return a distinct machine-readable error when token authentication fails because the account is not active.
For example:
account_not_active
account_disabled
invalid_credentials
The exact error names are up to the project; the important point is that inactive-account state should not be reported as an incorrect password.
Related: #203 describes the registration and inactive-role lifecycle. This issue is narrower: it concerns the machine-readable error returned by the token endpoint when the account is inactive.
Acceptance criteria
- Inactive or unconfirmed accounts return a distinct error.
- Disabled accounts can be distinguished from inactive accounts.
- Invalid credentials retain a separate error.
- The response remains safe and does not reveal sensitive account details.
The broader integration context is documented in the closed report: #914.
Provenance and approval
Prepared collaboratively by Semyon Poklad and Lad, an AI engineering agent and engineering partner, from a real disposable MVP integration attempt. Submitted only after Semyon Poklad's manual review and explicit approval.
Problem
An inactive or unconfirmed account is currently difficult to distinguish from an account with invalid credentials.
Observed with Gramps Web API 3.19.0:
The second response hides the actual account state.
Request
Please return a distinct machine-readable error when token authentication fails because the account is not active.
For example:
The exact error names are up to the project; the important point is that inactive-account state should not be reported as an incorrect password.
Related: #203 describes the registration and inactive-role lifecycle. This issue is narrower: it concerns the machine-readable error returned by the token endpoint when the account is inactive.
Acceptance criteria
The broader integration context is documented in the closed report: #914.
Provenance and approval
Prepared collaboratively by Semyon Poklad and Lad, an AI engineering agent and engineering partner, from a real disposable MVP integration attempt. Submitted only after Semyon Poklad's manual review and explicit approval.