feat: 完整游戏运维功能
This commit is contained in:
@@ -32,7 +32,7 @@ AI invocation responses must be bounded and must not include raw provider creden
|
||||
- `AIProviderCreateRequest`: create provider metadata with `apiKeyRef`, never raw key material.
|
||||
- `AIProviderUpdateRequest`: replace editable provider metadata while preserving status through the service layer.
|
||||
- `AIProviderStatusRequest`: set provider status to `active` or `disabled`.
|
||||
- `AIProviderResponse`: redacted provider response with `apiKeyRef` only.
|
||||
- `AIProviderResponse`: redacted provider response with `apiKeyConfigured` only; it does not expose the stored secret reference.
|
||||
- `AIProviderTestResponse`: local metadata validation result with `mode=metadata`; live external connectivity is deferred.
|
||||
- `AIProviderModelsResponse`: configured model list and default model, without credentials.
|
||||
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
# Authentication and Service Identity Contracts
|
||||
|
||||
## Platform bearer sessions
|
||||
|
||||
- Login and first-user registration issue a random bearer token with an eight-hour expiry.
|
||||
- Strict production HTTP routes deliver the session through an `HttpOnly`, `SameSite=Strict` cookie and omit it from JSON. `X-Auth-Token-Response: bearer` is an explicit CLI compatibility mode.
|
||||
- Durable stores keep only `AuthSessionRecord.tokenHash`, owner, generation, status, and lifecycle timestamps.
|
||||
- Logout and rotation set `status=revoked` and `revokedAt`; rotation issues a distinct generation.
|
||||
- Missing, unknown, expired, revoked, or disabled-user sessions return a safe `401 unauthorized` error.
|
||||
|
||||
## Authorization roles
|
||||
|
||||
- `platform-admin`: user/provider/plugin installation and state, Run endpoint administration, platform metrics, audit, and global internal resource creation.
|
||||
- server owner: server membership, runtime binding changes, destructive/archive operations, and all visible server actions.
|
||||
- server administrator: non-owner operational access to assigned server resources, but no owner-only membership or secret/key rotation.
|
||||
- Run service: control/job/log/artifact channels for its current endpoint session; it cannot use browser bearer authority.
|
||||
|
||||
Job, log, artifact, runtime-binding, distribution, and plugin-bridge services resolve the target server and repeat ownership checks independently from the HTTP router.
|
||||
|
||||
## Run signed envelope
|
||||
|
||||
Component-authenticated Run hello responses advertise `signed-envelope.v1.required`. Subsequent HTTP channel calls carry `X-Run-Endpoint`, `X-Run-Timestamp` (Unix seconds), `X-Run-Nonce`, and `X-Run-Signature` (hex HMAC-SHA256).
|
||||
|
||||
The canonical payload is `METHOD + "\n" + PATH + "\n" + TIMESTAMP + "\n" + NONCE + "\n" + SHA256(BODY)`. The current Run session token is the HMAC key. The platform rejects endpoint mismatch, invalid signatures, timestamps outside a five-minute window, expired/revoked sessions, and replayed nonces. Legacy non-component local test sessions remain an explicit compatibility path and advertise the envelope as optional.
|
||||
|
||||
## Secret boundary
|
||||
|
||||
Platform snapshots may contain password verifiers, bearer/Run token hashes, encrypted component-key ciphertext, fingerprints, generations, and controlled `secret://`/`vault://` references. They never contain raw bearer tokens, raw component keys, provider key values, host paths, or direct sockets. Browser DTOs expose secret presence/configured flags only.
|
||||
|
||||
Component-key ciphertext uses an injectable AES-GCM envelope derived from `PLATFORM_SECRET_ENVELOPE_KEY`; the built-in key is a disposable-development fallback only. This boundary is not a production KMS/vault. External key wrapping, KMS/HSM integration, multi-node replay coordination, envelope-key migration, and secret-value rotation remain deferred risks.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Dependency And Run Update Contracts
|
||||
|
||||
Platform owns the reviewable dependency catalog, immutable plan digest, selected server/profile/binding, endpoint target, distribution artifact, job attempt, and audit projection. Plugins and `platform_web` see only catalog/status/update projections. They never receive resolved host paths, commands, raw bindings, credentials, secret refs, Run/session/lease values, fencing hashes, PIDs, sockets, or artifact bodies.
|
||||
|
||||
## Dependency flow
|
||||
|
||||
1. `GET /api/v1/server-instances/{id}/dependencies` resolves the installed plugin version, complete runtime binding, online Run endpoint OS/architecture, target-matched probes/plans, and canonical SHA-256 digest.
|
||||
2. An install request must submit that exact digest. Platform re-resolves the declaration before creating `dependencies.install`; missing or stale approval is denied and audited.
|
||||
3. Run retrieves private input through signed `POST /api/v1/run/jobs/dependency-input` only for the active endpoint/session/attempt/lease and non-cancelled job. It executes closed command-version, Java, Docker, package, service, Steam, file, package-manager, verified HTTPS download, and SteamCMD adapters with bounded output/timeouts and a durable step journal.
|
||||
4. Terminal evidence is typed and redacted. Platform verifies probe key, plan digest, result checksum, and job attempt before updating `DependencyStatus`.
|
||||
|
||||
## Self-update flow
|
||||
|
||||
1. Platform accepts only an available Run distribution owned by the same server and matching the registered endpoint OS/architecture/checksum.
|
||||
2. Run retrieves private metadata through `update-input`, reads 1 MiB-or-smaller ranges through `update-chunk`, persists offsets, verifies the final artifact checksum, rejects traversal/links/devices/unexpected entries, and stages exactly the expected executable without replacing configuration.
|
||||
3. The terminal staged result moves the safe phase to `restart-requested`. The local journal persists the activation manifest before helper launch. The helper backs up/replaces atomically, starts the new binary with helper environment removed, waits for health, and rolls back on timeout or identity failure.
|
||||
4. The new Run reports success or rollback through signed `update-health` only after registration and job reconciliation. Platform then projects `succeeded` or `rolled-back`; a hello-only outcome is never treated as health confirmation.
|
||||
|
||||
Control heartbeat, job ack/result/cancel/reconcile, durable logs, and artifact upload use independent loops and deadlines. This contract does not include production code signing/KMS, rollout rings/fleet orchestration, client-manager lifecycle, plugin lifecycle, production scaling/alerts, external mirrors/storage, or real AI-provider integration.
|
||||
Reference in New Issue
Block a user