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:
@@ -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