feat: implement auth, projects, and frontend foundation
This commit is contained in:
@@ -3,12 +3,9 @@
|
||||
## Purpose
|
||||
|
||||
Manage user authentication via Authentik OAuth with secure session handling.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: OAuth2/OIDC Flow
|
||||
|
||||
The system SHALL support OAuth2/OIDC authentication via Authentik.
|
||||
The system SHALL support OAuth2/OIDC authentication via Authentik and SHALL validate Authentik-issued tokens via JWKS before creating local sessions.
|
||||
|
||||
#### Scenario: User login
|
||||
- GIVEN a user clicks the login button
|
||||
@@ -16,43 +13,57 @@ The system SHALL support OAuth2/OIDC authentication via Authentik.
|
||||
- THEN the user authenticates with Authentik
|
||||
- AND Authentik redirects back with authorization code
|
||||
|
||||
#### Scenario: Token exchange
|
||||
#### Scenario: Token exchange and validation
|
||||
- GIVEN Authentik has redirected with authorization code
|
||||
- WHEN the callback endpoint receives the code
|
||||
- THEN it exchanges the code for access and refresh tokens
|
||||
- AND sets httpOnly, Secure, SameSite=strict cookies
|
||||
- THEN it exchanges the code for provider tokens
|
||||
- AND verifies token signature and claims using Authentik JWKS
|
||||
- AND upserts the local user account
|
||||
- AND mints internal access and refresh tokens
|
||||
|
||||
### Requirement: Session Security
|
||||
The system SHALL protect sessions using httpOnly cookies and SHALL apply secure cookie defaults by environment.
|
||||
|
||||
The system SHALL protect sessions using httpOnly cookies.
|
||||
|
||||
#### Scenario: Cookie attributes
|
||||
- GIVEN successful authentication
|
||||
#### Scenario: Cookie attributes in production
|
||||
- GIVEN successful authentication in production
|
||||
- WHEN cookies are set
|
||||
- THEN access_token cookie SHALL be httpOnly
|
||||
- AND access_token cookie SHALL have Secure flag
|
||||
- AND access_token cookie SHALL have SameSite=strict
|
||||
- AND refresh_token cookie SHALL have same attributes
|
||||
- AND refresh_token cookie SHALL have the same attributes
|
||||
|
||||
#### Scenario: Cookie attributes in localhost development
|
||||
- GIVEN successful authentication in localhost development
|
||||
- WHEN cookies are set
|
||||
- THEN access_token cookie SHALL be httpOnly
|
||||
- AND access_token cookie SHALL have Secure=false
|
||||
- AND access_token cookie SHALL have SameSite=lax
|
||||
- AND refresh_token cookie SHALL have the same attributes
|
||||
|
||||
### Requirement: Token Refresh
|
||||
|
||||
The system SHALL support automatic token refresh.
|
||||
The system SHALL support automatic token refresh with server-side refresh token storage, rotation, and revocation.
|
||||
|
||||
#### Scenario: Access token expiration
|
||||
- GIVEN a user has an expired access token
|
||||
- WHEN the user makes an authenticated request
|
||||
- THEN the system uses the refresh token to get a new access token
|
||||
- WHEN the user makes an authenticated request that can refresh
|
||||
- THEN the system validates the refresh token against non-expired, non-revoked DB state
|
||||
- AND rotates the refresh token
|
||||
- AND issues a new internal access token
|
||||
|
||||
#### Scenario: Refresh token reuse detection
|
||||
- GIVEN a refresh token has already been rotated or revoked
|
||||
- WHEN it is presented again to the refresh endpoint
|
||||
- THEN the system rejects the request with unauthorized status
|
||||
- AND invalidates the token chain for the session
|
||||
|
||||
### Requirement: Session Termination
|
||||
|
||||
The system SHALL support explicit logout.
|
||||
The system SHALL support explicit logout with refresh token invalidation.
|
||||
|
||||
#### Scenario: User logout
|
||||
- GIVEN an authenticated user
|
||||
- WHEN the user clicks logout
|
||||
- THEN all auth cookies are cleared
|
||||
- AND the refresh token is invalidated
|
||||
- AND the refresh token is invalidated in server-side storage
|
||||
|
||||
## Dependencies
|
||||
|
||||
|
||||
@@ -3,12 +3,9 @@
|
||||
## Purpose
|
||||
|
||||
Provide a modern React frontend with TypeScript, routing, and responsive layout.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: React Application Setup
|
||||
|
||||
The system SHALL use React 18+ with TypeScript.
|
||||
The system SHALL use React 18+ with TypeScript and SHALL provide a runnable application source structure in `apps/web/src`.
|
||||
|
||||
#### Scenario: Frontend build
|
||||
- GIVEN the frontend codebase
|
||||
@@ -17,23 +14,24 @@ The system SHALL use React 18+ with TypeScript.
|
||||
- Use Vite as the build tool
|
||||
- Support Hot Module Replacement (HMR)
|
||||
- Output optimized production builds
|
||||
- Include a concrete entrypoint, app composition, and route tree
|
||||
|
||||
### Requirement: Client-Side Routing
|
||||
|
||||
The system SHALL implement client-side routing.
|
||||
The system SHALL implement client-side routing with authenticated route guards and explicit not-found handling.
|
||||
|
||||
#### Scenario: Navigation
|
||||
- GIVEN the frontend application
|
||||
- THEN React Router SHALL:
|
||||
- Define routes for all pages
|
||||
- Define routes for all foundation pages
|
||||
- Support protected routes (require authentication)
|
||||
- Handle 404 errors
|
||||
- Support route parameters
|
||||
- Support route parameters for feature pages
|
||||
|
||||
#### Scenario: Protected routes
|
||||
- GIVEN an unauthenticated user
|
||||
- WHEN they access a protected route
|
||||
- THEN they are redirected to login
|
||||
- THEN they are redirected to login flow
|
||||
- AND post-auth navigation returns them to an authenticated landing route
|
||||
|
||||
### Requirement: Styling Framework
|
||||
|
||||
@@ -48,16 +46,15 @@ The system SHALL use Tailwind CSS for styling.
|
||||
- Support dark mode
|
||||
|
||||
### Requirement: Layout Component
|
||||
|
||||
The system SHALL provide a consistent application layout.
|
||||
The system SHALL provide a consistent application layout for authenticated screens across desktop and mobile sizes.
|
||||
|
||||
#### Scenario: Application shell
|
||||
- GIVEN the frontend application
|
||||
- THEN a Layout component SHALL:
|
||||
- Display a header with user info and logout
|
||||
- Display a sidebar with navigation links
|
||||
- Display sidebar navigation on desktop
|
||||
- Show main content area
|
||||
- Collapse sidebar on mobile
|
||||
- Collapse sidebar into a mobile menu toggle on small viewports
|
||||
|
||||
#### Scenario: Navigation links
|
||||
- GIVEN the sidebar navigation
|
||||
@@ -81,19 +78,17 @@ The system SHALL support mobile devices.
|
||||
- Touch targets are appropriately sized
|
||||
|
||||
### Requirement: Loading States
|
||||
|
||||
The system SHALL handle asynchronous operations gracefully.
|
||||
The system SHALL handle asynchronous operations gracefully during auth bootstrap and dashboard fetches.
|
||||
|
||||
#### Scenario: Data fetching
|
||||
- GIVEN a page loading data
|
||||
- THEN:
|
||||
- Loading spinners/skeletons are shown
|
||||
- Error boundaries catch errors
|
||||
- Retry options are available on failure
|
||||
- Loading states are shown while requests are in flight
|
||||
- Errors are shown with retry affordance
|
||||
- Initial auth-check loading prevents protected-layout flicker
|
||||
|
||||
### Requirement: HTTP Client Configuration
|
||||
|
||||
The system SHALL configure HTTP requests properly.
|
||||
The system SHALL configure HTTP requests for cookie-based auth and unauthorized-session recovery.
|
||||
|
||||
#### Scenario: API communication
|
||||
- GIVEN the frontend application
|
||||
@@ -101,7 +96,7 @@ The system SHALL configure HTTP requests properly.
|
||||
- Send credentials (cookies) with requests
|
||||
- Handle 401 responses by redirecting to login
|
||||
- Set appropriate content-type headers
|
||||
- Support request/response interceptors
|
||||
- Support request/response interception in a shared client module
|
||||
|
||||
### Requirement: Dashboard Page
|
||||
|
||||
|
||||
Reference in New Issue
Block a user