3.7 KiB
3.7 KiB
ADDED Requirements
Requirement: Account login is the primary Console authentication flow
The Console SHALL use username/password login and a server-managed user session as its primary authentication flow, while retaining the existing tab-scoped bearer-token flow behind an explicit compatibility action.
Scenario: Operator opens the Console without authentication
- WHEN
/v1/auth/mereports no valid user session and no compatibility bearer token is active - THEN the Console displays the username/password login form as the primary action and offers a secondary “Use API token” action
Scenario: Login succeeds
- WHEN an operator submits valid account credentials
- THEN the Console enters session mode, displays the authenticated user's identity, and loads only views allowed by the returned effective scopes
Scenario: Login fails
- WHEN the login endpoint rejects credentials or throttles the attempt
- THEN the Console shows the generic authentication failure without revealing whether the username exists or persisting the password
Scenario: Operator chooses token compatibility
- WHEN an operator explicitly selects “Use API token” and enters a bearer token
- THEN the Console retains that token only in tab-scoped session storage and uses the existing bearer request behavior
Requirement: Console manages authenticated session lifecycle
The Console SHALL send cookies on user-session requests, attach session CSRF proof to unsafe requests, provide logout and password-change controls, and distinguish authentication loss from insufficient authorization.
Scenario: User logs out
- WHEN a logged-in user activates logout
- THEN the Console submits CSRF-protected logout, clears local authentication state, and returns to the login screen
Scenario: Session expires
- WHEN a session-authenticated request returns
401 - THEN the Console clears session UI state and returns to login with a session-expired message
Scenario: User lacks a required scope
- WHEN an otherwise valid session-authenticated request returns
403 - THEN the Console preserves the session and shows an authorization error for that operation
Scenario: User must change a temporary password
- WHEN the current-user response sets
must_change_password - THEN the Console restricts navigation to password change and logout until password change succeeds
Requirement: Administrators manage users from the Console
The Console SHALL expose a user-management view only to principals whose effective scopes include users:admin, with controls to list/create users, change role or enabled state, reset passwords, and revoke sessions.
Scenario: Administrator opens user management
- WHEN an authenticated administrator opens the Users view
- THEN the Console displays non-secret user records and the supported lifecycle controls without exposing password or session credential material
Scenario: Administrator creates an account
- WHEN an administrator submits valid user details and an initial password
- THEN the Console creates the account, clears password fields immediately, and shows that the new user must change the initial password
Scenario: Non-admin loads the Console
- WHEN the current principal lacks
users:admin - THEN the Console does not render the Users navigation or management controls, while backend authorization remains authoritative
Scenario: User-management mutation fails
- WHEN a create, update, reset, or revoke request returns validation, conflict, or authorization failure
- THEN the Console preserves non-secret form state as appropriate, clears all password fields, and displays the API error without retrying the mutation automatically