Lukas
1c673d600c
This commit standardizes how API responses are wrapped, solving issue #24. Problem: - Inconsistent response envelopes (jails vs items vs bans vs no wrapper) - Frontend required multiple field name variants - Integration bugs from branching logic - No clear pattern for different response types Solution: - Created response.py with base classes: PaginatedListResponse, CollectionResponse, CommandResponse - Standardized all list/collection responses to use 'items' field - Domain-specific field names for detail and aggregation responses - Updated all backends routers and mappers - Updated frontend types and hooks to match Changes: Backend: - backend/app/models/response.py (new): Base response models - backend/app/models/ban.py: Updated responses to inherit from bases - backend/app/models/jail.py: Updated JailListResponse, JailCommandResponse - backend/app/models/config.py: Updated collection responses - backend/app/services/jail_service.py: Updated return statements - backend/app/mappers/ban_mappers.py: Updated 'bans' to 'items' - backend/tests/test_mappers/test_ban_mappers.py: Updated tests Frontend: - frontend/src/types/jail.ts: Updated response interfaces - frontend/src/types/config.ts: Updated response interfaces - frontend/src/hooks/useActiveBans.ts: Updated selector - frontend/src/hooks/useJailList.ts: Updated selector - frontend/src/hooks/useJailConfigs.ts: Updated selector - frontend/src/hooks/useConfigActiveStatus.ts: Updated field access - frontend/src/hooks/useJailAdmin.ts: Updated field access Documentation: - Docs/Backend-Development.md: Added § 4.1 API Response Envelope Policy The policy defines: 1. Paginated lists use PaginatedListResponse (items, total, page, page_size) 2. Non-paginated collections use CollectionResponse (items, total) 3. Detail responses use entity-specific field names (jail, status, settings) 4. Command responses use CommandResponse (message, success, optional target) 5. Aggregations use domain-specific fields (jails, countries, buckets, bans) All responses now follow one of these patterns, reducing frontend complexity. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
12 KiB
12 KiB
24) API response wrapper shape is inconsistent
- Where found:
- Why this is needed:
- Inconsistent payload envelopes increase frontend branching and integration bugs.
- Goal:
- Define and enforce a consistent response envelope policy.
- What to do:
- Standardize endpoint response forms.
- Align frontend typing and parsing strategy.
- Possible traps and issues:
- Breaking contract for existing clients.
- Docs changes needed:
- Add API response style guide.
- Doc references:
25) No canonical snake_case/camelCase serialization policy
- Where found:
- Why this is needed:
- Naming convention drift causes brittle frontend-backend contracts.
- Goal:
- Enforce one API field naming policy.
- What to do:
- Configure model aliasing strategy and update frontend contracts.
- Possible traps and issues:
- Partial migration can leave mixed payload formats.
- Docs changes needed:
- Add naming convention section for API fields.
- Doc references:
26) Pagination contract is not standardized across endpoints
- Where found:
- Why this is needed:
- Different pagination patterns increase frontend complexity.
- Goal:
- Use one shared paginated response model.
- What to do:
- Introduce common pagination schema and query parameter policy.
- Possible traps and issues:
- Existing endpoint consumers may require transition period.
- Docs changes needed:
- Add pagination API spec.
- Doc references:
27) Error response body shape is inconsistent
- Where found:
- Why this is needed:
- Frontend cannot reliably branch on machine-readable error codes.
- Goal:
- Standard error response schema with code + detail + metadata.
- What to do:
- Add shared error model and update handlers.
- Possible traps and issues:
- Legacy consumers parsing detail strings may break.
- Docs changes needed:
- Add backend error schema and mapping table.
- Doc references:
28) Login failure delay can enable app-layer DoS
- Where found:
- Why this is needed:
- Fixed 10-second await for invalid login attempts can amplify load impact.
- Goal:
- Keep brute-force resistance without exhausting request capacity.
- What to do:
- Replace fixed sleep with limiter-backed penalty strategy and concurrency protection.
- Possible traps and issues:
- Too little penalty weakens brute-force protection.
- Docs changes needed:
- Document authentication throttling strategy.
- Doc references:
29) Blocklist URL validation has DNS-rebinding window
- Where found:
- Why this is needed:
- Validation at create/update does not guarantee safe runtime destination.
- Goal:
- Enforce SSRF safety at connect/request time as well.
- What to do:
- Add runtime destination/IP allow-deny validation in HTTP layer.
- Possible traps and issues:
- Resolver/cache behavior may vary across environments.
- Docs changes needed:
- Add blocklist network security notes and runtime checks.
- Doc references:
30) Setup persistence is non-atomic across DB contexts
- Where found:
- Why this is needed:
- Partial commits during setup can leave inconsistent state.
- Goal:
- Make setup operations transactional and crash-safe.
- What to do:
- Introduce staged setup state and transaction boundaries.
- Possible traps and issues:
- SQLite transaction handling across multiple DB files is limited.
- Docs changes needed:
- Add setup state machine and rollback behavior.
- Doc references:
31) Fire-and-forget reschedule may fail silently
- Where found:
- Why this is needed:
- Schedule update requests can succeed while background reschedule fails.
- Goal:
- Make schedule updates deterministic and observable.
- What to do:
- Await reschedule path or persist task outcome status and surface errors.
- Possible traps and issues:
- Blocking request path might add latency if scheduler is busy.
- Docs changes needed:
- Document scheduling reliability guarantees.
- Doc references:
32) RateLimiter cleanup function is not scheduled/used
- Where found:
- Why this is needed:
- Rate limiter state can grow over long runtimes.
- Goal:
- Ensure periodic cleanup or bounded memory strategy.
- What to do:
- Add scheduled cleanup or auto-eviction structure.
- Possible traps and issues:
- Cleanup cadence too frequent can add overhead.
- Docs changes needed:
- Add operational notes for auth throttling lifecycle.
- Doc references:
33) Trusted proxy configuration is hardcoded in auth router
- Where found:
- Why this is needed:
- Incorrect client IP extraction can break per-IP rate limiting behind proxies.
- Goal:
- Move trusted proxies to validated runtime config.
- What to do:
- Add settings for trusted proxy IPs/CIDRs.
- Validate and use these in client IP extraction.
- Possible traps and issues:
- Over-trusting headers can enable spoofing.
- Docs changes needed:
- Add reverse-proxy deployment configuration section.
- Doc references:
34) Setup redirect allowlist uses broad prefix matching
- Where found:
- Why this is needed:
- Prefix-based allow rules are fragile for future route additions.
- Goal:
- Use exact path or route-level allow policy.
- What to do:
- Replace startswith matching with explicit allowlist checks.
- Possible traps and issues:
- API docs and setup flow paths must remain reachable.
- Docs changes needed:
- Add setup guard route policy documentation.
- Doc references:
35) API client sends JSON and CSRF header for every request method
- Where found:
- Why this is needed:
- Extra headers on GET increase unnecessary CORS preflights and noise.
- Goal:
- Apply headers by method/body requirements.
- What to do:
- Only set Content-Type for requests with JSON body.
- Send CSRF header for mutating cookie-authenticated requests only.
- Possible traps and issues:
- CSRF protection assumptions must still hold for all mutating paths.
- Docs changes needed:
- Update frontend API client contract and CSRF notes.
- Doc references:
36) Polling continues when tab is not visible
- Where found:
- Why this is needed:
- Unnecessary backend load and client resource usage in background tabs.
- Goal:
- Pause/reduce polling when page is hidden.
- What to do:
- Add visibility-aware polling strategy and optional backoff.
- Possible traps and issues:
- Data may appear stale immediately after tab restore if refresh is delayed.
- Docs changes needed:
- Add frontend polling lifecycle policy.
- Doc references:
37) Multi-worker safety check depends on one environment variable
- Where found:
- Why this is needed:
- Other process managers can still launch multiple workers without this variable.
- Goal:
- Enforce scheduler single-executor safety regardless of launcher.
- What to do:
- Add robust single-run lock/leader mechanism for scheduler ownership.
- Possible traps and issues:
- Locking strategy must be reliable in container orchestration.
- Docs changes needed:
- Expand deployment constraints and supported run modes.
- Doc references:
38) History archive query paths may need explicit indexing plan
- Where found:
- Why this is needed:
- Large archive datasets can degrade filter/sort performance.
- Goal:
- Add indexes aligned with real query patterns.
- What to do:
- Benchmark common history queries.
- Add migration with targeted indexes.
- Possible traps and issues:
- Extra indexes increase write cost and DB size.
- Docs changes needed:
- Add DB performance/indexing section for history.
- Doc references:
39) No explicit DI container strategy for backend service graph
- Where found:
- Why this is needed:
- Dependency construction and lifecycle are partly implicit.
- Goal:
- Define a clear dependency wiring pattern for services and repositories.
- What to do:
- Create service composition root pattern and document usage.
- Possible traps and issues:
- Over-engineering if container abstraction is too heavy for current size.
- Docs changes needed:
- Add dependency wiring chapter.
- Doc references:
40) Frontend and backend observability are not aligned
- Where found:
- Why this is needed:
- Backend uses structured logging while frontend error telemetry is mostly local and ad-hoc.
- Goal:
- Define unified error telemetry and correlation approach.
- What to do:
- Introduce frontend error reporting pipeline and request correlation IDs.
- Possible traps and issues:
- PII/sensitive payload leakage risk in client-side telemetry.
- Docs changes needed:
- Add observability and privacy-safe logging guidelines.
- Doc references: