sirily
1a7250467e
## Summary - harden the web runtime with JSON body limits, stricter generation input validation, rate limiting, and trusted Origin/Referer checks for cookie-authenticated mutations - redact password-reset tokens from debug email transport logs and fail closed for unsupported email providers - scope generation idempotency keys per user with a Prisma migration and regression coverage ## Testing - docker build -f infra/docker/web.Dockerfile -t nroxy-web-check . - docker run --rm --entrypoint sh nroxy-web-check -lc "pnpm --filter @nproxy/providers test && pnpm --filter @nproxy/db test && pnpm --filter @nproxy/web test" Closes #14 Closes #7 Closes #8 Co-authored-by: sirily <sirily@git.shararam.party> Reviewed-on: #21
40 lines
2.1 KiB
Markdown
40 lines
2.1 KiB
Markdown
# System Overview
|
|
|
|
## Runtime components
|
|
- `apps/web`: public site, user dashboard, admin UI, HTTP API handlers
|
|
- `apps/worker`: background jobs for generation execution, reconciliation, cleanup, and health checks
|
|
- `apps/bot`: Telegram admin bot runtime
|
|
- `apps/cli`: operator commands executed on the server
|
|
|
|
## Shared packages
|
|
- `packages/config`: environment parsing and config contracts
|
|
- `packages/db`: Prisma schema, migrations, data access helpers
|
|
- `packages/domain`: business rules and state machines
|
|
- `packages/providers`: external adapters for model APIs, payment processor, storage, email, and Telegram
|
|
|
|
## Core request flow
|
|
1. User submits a generation request from the chat UI.
|
|
2. The web app validates auth, subscription, quota, and request shape.
|
|
3. The app stores a `GenerationRequest` and enqueues work.
|
|
4. The worker runs provider routing through the key pool.
|
|
5. The worker persists `GenerationAttempt` rows for each key-level attempt.
|
|
6. On the first success, the worker stores assets, marks the request succeeded, and consumes quota.
|
|
7. The web app exposes polling endpoints until the result is ready.
|
|
|
|
## Data boundaries
|
|
- User-visible request lifecycle lives in `GenerationRequest`.
|
|
- Key-level retries live in `GenerationAttempt`.
|
|
- Quota accounting lives in `UsageLedgerEntry`.
|
|
- Provider key health lives in `ProviderKey` plus status-event history.
|
|
|
|
## Failure handling
|
|
- Retryable provider failures are hidden from the user while eligible keys remain.
|
|
- User-caused provider failures are terminal for that request.
|
|
- Balance or quota exhaustion removes a key from active rotation.
|
|
- Provider-key state transitions must be audited.
|
|
|
|
## Web session posture
|
|
- Browser sessions use `Secure`, `HttpOnly`, `SameSite=Strict` cookies.
|
|
- State-changing cookie-authenticated endpoints accept requests only from the configured app/admin origins and require browser `Origin` or `Referer` metadata.
|
|
- The current API posture assumes a same-origin browser client. If cross-site embeds or third-party POST flows are introduced later, add an explicit CSRF token mechanism instead of relaxing the cookie/origin checks.
|