feat: implement security, error resilience, and query optimization proposals
Security Validation (enhance-security-validation): - JWT secret validation with entropy checking and pattern detection - CSRF protection middleware with token generation/validation - Frontend CSRF token auto-injection for DELETE/PUT/PATCH requests - MIME type validation with magic bytes detection for file uploads Error Resilience (add-error-resilience): - React ErrorBoundary component with fallback UI and retry functionality - ErrorBoundaryWithI18n wrapper for internationalization support - Page-level and section-level error boundaries in App.tsx Query Performance (optimize-query-performance): - Query monitoring utility with threshold warnings - N+1 query fixes using joinedload/selectinload - Optimized project members, tasks, and subtasks endpoints Bug Fixes: - WebSocket session management (P0): Return primitives instead of ORM objects - LIKE query injection (P1): Escape special characters in search queries Tests: 543 backend tests, 56 frontend tests passing Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
beabigegg
@@ -0,0 +1,19 @@
|
||||
# Change: Add Frontend Error Resilience
|
||||
|
||||
## Why
|
||||
|
||||
QA review identified that the frontend lacks React Error Boundaries. When a render error occurs in any component, the entire application crashes with a white screen, providing no recovery path for users.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Add React Error Boundary components around major application sections
|
||||
- Implement graceful degradation with user-friendly error messages
|
||||
- Add error reporting mechanism to capture frontend crashes
|
||||
|
||||
## Impact
|
||||
|
||||
- Affected specs: `dashboard`
|
||||
- Affected code:
|
||||
- `frontend/src/components/ErrorBoundary.tsx` - New component
|
||||
- `frontend/src/App.tsx` - Wrap routes with Error Boundaries
|
||||
- `frontend/src/pages/` - Section-level boundaries
|
||||
@@ -0,0 +1,24 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Error Boundary Protection
|
||||
The frontend application SHALL gracefully handle component render errors without crashing the entire application.
|
||||
|
||||
#### Scenario: Component error contained
|
||||
- **WHEN** a render error occurs in a dashboard widget
|
||||
- **THEN** only that widget SHALL display an error state
|
||||
- **AND** other widgets SHALL continue to function normally
|
||||
|
||||
#### Scenario: User-friendly error display
|
||||
- **WHEN** a component fails to render
|
||||
- **THEN** users SHALL see a friendly error message
|
||||
- **AND** users SHALL have an option to retry or report the issue
|
||||
|
||||
#### Scenario: Error logging
|
||||
- **WHEN** a render error is caught by an Error Boundary
|
||||
- **THEN** the error details SHALL be logged for debugging
|
||||
- **AND** error context (component stack) SHALL be captured
|
||||
|
||||
#### Scenario: Recovery option
|
||||
- **WHEN** a user sees an error fallback UI
|
||||
- **AND** the user clicks "Retry"
|
||||
- **THEN** the failed component SHALL attempt to re-render
|
||||
@@ -0,0 +1,14 @@
|
||||
## 1. Error Boundary Implementation
|
||||
- [x] 1.1 Create base ErrorBoundary component with fallback UI
|
||||
- [x] 1.2 Add error logging/reporting to ErrorBoundary
|
||||
- [x] 1.3 Create user-friendly error fallback designs
|
||||
|
||||
## 2. Application Integration
|
||||
- [x] 2.1 Wrap main App routes with top-level Error Boundary
|
||||
- [x] 2.2 Add section-level boundaries around Dashboard, Tasks, Projects
|
||||
- [x] 2.3 Add component-level boundaries for complex widgets
|
||||
|
||||
## 3. Testing
|
||||
- [x] 3.1 Write tests for ErrorBoundary component
|
||||
- [x] 3.2 Add integration tests that verify graceful degradation
|
||||
- [x] 3.3 Test error recovery flow
|
||||
@@ -0,0 +1,22 @@
|
||||
# Change: Enhance Security Validation
|
||||
|
||||
## Why
|
||||
|
||||
QA review identified several security gaps that could be exploited:
|
||||
1. JWT secret keys lack entropy validation, allowing weak secrets
|
||||
2. File uploads only check extensions, not actual MIME types (content spoofing risk)
|
||||
3. Missing CSRF protection on sensitive state-changing operations
|
||||
|
||||
## What Changes
|
||||
|
||||
- **user-auth**: Add JWT secret key strength validation (minimum length, entropy check)
|
||||
- **user-auth**: Add CSRF token validation for sensitive operations
|
||||
- **document-management**: Add file MIME type validation using magic bytes detection
|
||||
|
||||
## Impact
|
||||
|
||||
- Affected specs: `user-auth`, `document-management`
|
||||
- Affected code:
|
||||
- `backend/app/core/security.py` - JWT validation
|
||||
- `backend/app/api/v1/endpoints/` - CSRF middleware
|
||||
- `backend/app/services/file_service.py` - MIME validation
|
||||
@@ -0,0 +1,23 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: File MIME Type Validation
|
||||
The system SHALL validate file content type using magic bytes detection.
|
||||
|
||||
#### Scenario: Valid file with matching extension
|
||||
- **WHEN** a user uploads a file
|
||||
- **AND** the detected MIME type matches the file extension
|
||||
- **THEN** the upload SHALL be accepted
|
||||
|
||||
#### Scenario: Spoofed file extension rejected
|
||||
- **WHEN** a user uploads a file with extension `.jpg`
|
||||
- **AND** the actual content is detected as `application/x-executable`
|
||||
- **THEN** the upload SHALL be rejected with error "File type mismatch"
|
||||
|
||||
#### Scenario: Unsupported MIME type rejected
|
||||
- **WHEN** a user uploads a file with an unsupported MIME type
|
||||
- **THEN** the upload SHALL be rejected with error "Unsupported file type"
|
||||
|
||||
#### Scenario: MIME validation bypass for trusted sources
|
||||
- **WHEN** a file is uploaded from a trusted internal source
|
||||
- **AND** the system is configured to allow bypass
|
||||
- **THEN** MIME validation MAY be skipped
|
||||
@@ -0,0 +1,30 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: JWT Secret Validation
|
||||
The system SHALL validate JWT secret key strength on startup.
|
||||
|
||||
#### Scenario: Weak secret rejected
|
||||
- **WHEN** the configured JWT secret is less than 32 characters
|
||||
- **THEN** the system SHALL log a critical warning
|
||||
- **AND** optionally refuse to start in production mode
|
||||
|
||||
#### Scenario: Low entropy secret warning
|
||||
- **WHEN** the JWT secret has low entropy (repeating patterns, common words)
|
||||
- **THEN** the system SHALL log a security warning
|
||||
|
||||
### Requirement: CSRF Protection
|
||||
The system SHALL protect sensitive state-changing operations with CSRF tokens.
|
||||
|
||||
#### Scenario: CSRF token required for password change
|
||||
- **WHEN** a user attempts to change their password
|
||||
- **AND** the request does not include a valid CSRF token
|
||||
- **THEN** the request SHALL be rejected with 403 Forbidden
|
||||
|
||||
#### Scenario: CSRF token required for account deletion
|
||||
- **WHEN** a user attempts to delete their account or resources
|
||||
- **AND** the request does not include a valid CSRF token
|
||||
- **THEN** the request SHALL be rejected with 403 Forbidden
|
||||
|
||||
#### Scenario: Valid CSRF token accepted
|
||||
- **WHEN** a state-changing request includes a valid CSRF token
|
||||
- **THEN** the request SHALL proceed normally
|
||||
@@ -0,0 +1,19 @@
|
||||
## 1. JWT Secret Validation
|
||||
- [x] 1.1 Add minimum secret length check (32+ characters)
|
||||
- [x] 1.2 Add entropy validation for JWT secret
|
||||
- [x] 1.3 Log warning on startup if secret is weak
|
||||
- [x] 1.4 Write unit tests for secret validation
|
||||
|
||||
## 2. CSRF Protection
|
||||
- [x] 2.1 Add CSRF token generation utility
|
||||
- [x] 2.2 Add CSRF validation middleware
|
||||
- [x] 2.3 Apply to sensitive endpoints (password change, delete operations)
|
||||
- [x] 2.4 Update frontend to include CSRF token in requests
|
||||
- [x] 2.5 Write integration tests for CSRF validation
|
||||
|
||||
## 3. MIME Type Validation
|
||||
- [x] 3.1 Add python-magic or similar library for MIME detection
|
||||
- [x] 3.2 Implement magic bytes validation in file upload service
|
||||
- [x] 3.3 Reject files where extension doesn't match actual content
|
||||
- [x] 3.4 Add configurable allowed MIME types per file category
|
||||
- [x] 3.5 Write unit tests for MIME validation
|
||||
@@ -0,0 +1,19 @@
|
||||
# Change: Optimize Database Query Performance
|
||||
|
||||
## Why
|
||||
|
||||
QA review identified N+1 query patterns in project member listing and related endpoints. When loading a project with many members, each member triggers a separate database query, causing significant performance degradation.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Implement eager loading (joinedload) for project member relationships
|
||||
- Add query batching for related entity loading
|
||||
- Add database query logging in development mode for detection
|
||||
|
||||
## Impact
|
||||
|
||||
- Affected specs: `resource-management`
|
||||
- Affected code:
|
||||
- `backend/app/services/project_service.py` - Member loading
|
||||
- `backend/app/api/v1/endpoints/projects.py` - Query optimization
|
||||
- `backend/app/models/` - Relationship configurations
|
||||
@@ -0,0 +1,19 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Optimized Relationship Loading
|
||||
The system SHALL use efficient query patterns to avoid N+1 query problems when loading related entities.
|
||||
|
||||
#### Scenario: Project member list loading
|
||||
- **WHEN** loading a project with its members
|
||||
- **THEN** the system SHALL load all members in at most 2 database queries
|
||||
- **AND** NOT one query per member
|
||||
|
||||
#### Scenario: Task assignee loading
|
||||
- **WHEN** loading a list of tasks with their assignees
|
||||
- **THEN** the system SHALL batch load assignee details
|
||||
- **AND** NOT query each assignee individually
|
||||
|
||||
#### Scenario: Query count monitoring
|
||||
- **WHEN** running in development mode
|
||||
- **THEN** the system SHALL log query counts per request
|
||||
- **AND** warn when query count exceeds threshold (e.g., 10 queries)
|
||||
@@ -0,0 +1,53 @@
|
||||
## 1. Query Analysis
|
||||
- [x] 1.1 Enable SQLAlchemy query logging in development
|
||||
- [x] 1.2 Identify all N+1 query patterns
|
||||
- [x] 1.3 Document current query counts per endpoint
|
||||
|
||||
## 2. Optimization Implementation
|
||||
- [x] 2.1 Add joinedload for project member relationships
|
||||
- [x] 2.2 Add selectinload for task assignee relationships
|
||||
- [x] 2.3 Implement batch loading for user details
|
||||
- [x] 2.4 Add appropriate indexes if missing
|
||||
|
||||
## 3. Verification
|
||||
- [x] 3.1 Benchmark before/after query counts
|
||||
- [x] 3.2 Write performance regression tests
|
||||
- [x] 3.3 Document optimization patterns for future reference
|
||||
|
||||
---
|
||||
|
||||
## Implementation Summary
|
||||
|
||||
### Changes Made
|
||||
|
||||
1. **Query Monitoring Module** (`app/core/query_monitor.py`)
|
||||
- Added `QueryCounter` context manager for counting queries per request
|
||||
- Integrated SQLAlchemy event listeners for query logging
|
||||
- Added threshold-based warnings when query count exceeds limit
|
||||
- Configurable via `QUERY_LOGGING` and `QUERY_COUNT_THRESHOLD` settings
|
||||
|
||||
2. **Configuration Updates** (`app/core/config.py`)
|
||||
- Added `DEBUG`, `QUERY_LOGGING`, `QUERY_COUNT_THRESHOLD` settings
|
||||
|
||||
3. **Project Router Optimizations** (`app/api/projects/router.py`)
|
||||
- `list_projects_in_space`: Added `joinedload` for owner, space, department; `selectinload` for tasks
|
||||
- `list_project_members`: Added `joinedload` for user (with department) and added_by_user
|
||||
|
||||
4. **Task Router Optimizations** (`app/api/tasks/router.py`)
|
||||
- `list_tasks`: Added `selectinload` for assignee, status, creator, subtasks, custom_values
|
||||
- `list_subtasks`: Added `selectinload` for assignee, status, creator, subtasks
|
||||
|
||||
5. **Performance Tests** (`tests/test_query_performance.py`)
|
||||
- Test cases for project member list optimization
|
||||
- Test cases for project list optimization
|
||||
- Test cases for task list optimization
|
||||
- Test cases for subtask list optimization
|
||||
|
||||
### Query Count Improvements
|
||||
|
||||
| Endpoint | Before (N members/tasks) | After |
|
||||
|----------|-------------------------|-------|
|
||||
| `/api/projects/{id}/members` | 1 + 2N queries | 2-3 queries |
|
||||
| `/api/spaces/{id}/projects` | 1 + 4N queries | 4-5 queries |
|
||||
| `/api/projects/{id}/tasks` | 1 + 4N queries | 5-6 queries |
|
||||
| `/api/tasks/{id}/subtasks` | 1 + 4N queries | 4-5 queries |
|
||||
@@ -161,3 +161,26 @@ The system SHALL support project templates to standardize project creation.
|
||||
- **THEN** system creates template with project's CustomField definitions
|
||||
- **THEN** template is available for future project creation
|
||||
|
||||
### Requirement: Error Boundary Protection
|
||||
The frontend application SHALL gracefully handle component render errors without crashing the entire application.
|
||||
|
||||
#### Scenario: Component error contained
|
||||
- **WHEN** a render error occurs in a dashboard widget
|
||||
- **THEN** only that widget SHALL display an error state
|
||||
- **AND** other widgets SHALL continue to function normally
|
||||
|
||||
#### Scenario: User-friendly error display
|
||||
- **WHEN** a component fails to render
|
||||
- **THEN** users SHALL see a friendly error message
|
||||
- **AND** users SHALL have an option to retry or report the issue
|
||||
|
||||
#### Scenario: Error logging
|
||||
- **WHEN** a render error is caught by an Error Boundary
|
||||
- **THEN** the error details SHALL be logged for debugging
|
||||
- **AND** error context (component stack) SHALL be captured
|
||||
|
||||
#### Scenario: Recovery option
|
||||
- **WHEN** a user sees an error fallback UI
|
||||
- **AND** the user clicks "Retry"
|
||||
- **THEN** the failed component SHALL attempt to re-render
|
||||
|
||||
|
||||
@@ -193,6 +193,28 @@ The system SHALL warn users when deleting tasks with unresolved blockers.
|
||||
- **THEN** system auto-resolves all blockers with "task deleted" reason
|
||||
- **THEN** system proceeds with task deletion
|
||||
|
||||
### Requirement: File MIME Type Validation
|
||||
The system SHALL validate file content type using magic bytes detection.
|
||||
|
||||
#### Scenario: Valid file with matching extension
|
||||
- **WHEN** a user uploads a file
|
||||
- **AND** the detected MIME type matches the file extension
|
||||
- **THEN** the upload SHALL be accepted
|
||||
|
||||
#### Scenario: Spoofed file extension rejected
|
||||
- **WHEN** a user uploads a file with extension `.jpg`
|
||||
- **AND** the actual content is detected as `application/x-executable`
|
||||
- **THEN** the upload SHALL be rejected with error "File type mismatch"
|
||||
|
||||
#### Scenario: Unsupported MIME type rejected
|
||||
- **WHEN** a user uploads a file with an unsupported MIME type
|
||||
- **THEN** the upload SHALL be rejected with error "Unsupported file type"
|
||||
|
||||
#### Scenario: MIME validation bypass for trusted sources
|
||||
- **WHEN** a file is uploaded from a trusted internal source
|
||||
- **AND** the system is configured to allow bypass
|
||||
- **THEN** MIME validation MAY be skipped
|
||||
|
||||
## Data Model
|
||||
|
||||
```
|
||||
|
||||
@@ -178,6 +178,24 @@ The system SHALL support explicit project membership to enable cross-department
|
||||
- **WHEN** a user not in project membership list attempts to access confidential project
|
||||
- **THEN** system denies access unless user is in the project's department
|
||||
|
||||
### Requirement: Optimized Relationship Loading
|
||||
The system SHALL use efficient query patterns to avoid N+1 query problems when loading related entities.
|
||||
|
||||
#### Scenario: Project member list loading
|
||||
- **WHEN** loading a project with its members
|
||||
- **THEN** the system SHALL load all members in at most 2 database queries
|
||||
- **AND** NOT one query per member
|
||||
|
||||
#### Scenario: Task assignee loading
|
||||
- **WHEN** loading a list of tasks with their assignees
|
||||
- **THEN** the system SHALL batch load assignee details
|
||||
- **AND** NOT query each assignee individually
|
||||
|
||||
#### Scenario: Query count monitoring
|
||||
- **WHEN** running in development mode
|
||||
- **THEN** the system SHALL log query counts per request
|
||||
- **AND** warn when query count exceeds threshold (e.g., 10 queries)
|
||||
|
||||
## Data Model
|
||||
|
||||
```
|
||||
|
||||
@@ -168,6 +168,35 @@ The system SHALL prevent file path traversal attacks by validating all file path
|
||||
- **THEN** system resolves path and verifies it is within storage directory
|
||||
- **THEN** system processes file operation normally
|
||||
|
||||
### Requirement: JWT Secret Validation
|
||||
The system SHALL validate JWT secret key strength on startup.
|
||||
|
||||
#### Scenario: Weak secret rejected
|
||||
- **WHEN** the configured JWT secret is less than 32 characters
|
||||
- **THEN** the system SHALL log a critical warning
|
||||
- **AND** optionally refuse to start in production mode
|
||||
|
||||
#### Scenario: Low entropy secret warning
|
||||
- **WHEN** the JWT secret has low entropy (repeating patterns, common words)
|
||||
- **THEN** the system SHALL log a security warning
|
||||
|
||||
### Requirement: CSRF Protection
|
||||
The system SHALL protect sensitive state-changing operations with CSRF tokens.
|
||||
|
||||
#### Scenario: CSRF token required for password change
|
||||
- **WHEN** a user attempts to change their password
|
||||
- **AND** the request does not include a valid CSRF token
|
||||
- **THEN** the request SHALL be rejected with 403 Forbidden
|
||||
|
||||
#### Scenario: CSRF token required for account deletion
|
||||
- **WHEN** a user attempts to delete their account or resources
|
||||
- **AND** the request does not include a valid CSRF token
|
||||
- **THEN** the request SHALL be rejected with 403 Forbidden
|
||||
|
||||
#### Scenario: Valid CSRF token accepted
|
||||
- **WHEN** a state-changing request includes a valid CSRF token
|
||||
- **THEN** the request SHALL proceed normally
|
||||
|
||||
## Data Model
|
||||
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user