59 lines
3.7 KiB
Markdown
59 lines
3.7 KiB
Markdown
## 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/me` reports 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
|