first commit

2026-07-11 14:56:10 +08:00
commit 7e05d0a4e7
660 changed files with 78119 additions and 0 deletions
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-07-04
@@ -0,0 +1,16 @@
+## Design
+
+- Sessions are in-memory platform sessions keyed by a random bearer token. Clients send the token as `Authorization: Bearer <token>`.
+- The local development platform seeds one explicit platform administrator account so real login can reach the admin console:
+  - account/email: `operator.local@example.test`
+  - password: `operator-local`
+- Passwords are stored as PBKDF2-SHA256 hashes with per-user salts using only Go standard library primitives.
+- Public registration creates a pending user with `server-admin` role and returns `status=pending` rather than authenticating the user.
+- Current-user profile and theme updates operate only on the authenticated session user and return bounded DTOs.
+- User management updates reuse `PUT /api/v1/users/{id}` and allow status, roles, display name, email, and profile fields to be changed through service validation.
+
+## Security Notes
+
+- Password hashes are not returned in DTOs.
+- Pending/disabled users cannot log in.
+- The frontend local fallback is disabled unless `VITE_ENABLE_LOCAL_AUTH_FALLBACK=true`, and its fallback user is not a platform admin.
@@ -0,0 +1,17 @@
+## Why
+
+The platform_web console already calls authentication, current-user, profile, theme, and user update endpoints, but the platform API has those routes deferred. That mismatch makes login/register appear broken and encourages the frontend local fallback to grant a platform administrator session without credentials.
+
+## What Changes
+
+- Add a minimal first-party username/email + password session API for login, registration, logout, and current-user lookup.
+- Store password hashes in platform-owned user records and never expose password material to platform_web.
+- Default public registration to pending server-admin scope instead of platform administrator privileges.
+- Add controlled user update support so the 用户管理 page can change user status through the API.
+- Restrict frontend local fallback to development/demo mode and downgrade it away from platform administrator privileges.
+
+## Impact
+
+- Affects `platform/` and `platform_web/`.
+- Keeps authentication in platform only; plugins do not receive raw credentials or auth secrets.
+- Does not add OAuth, SMS, production persistence, billing, cloud host sales, or unrelated marketplace behavior.
@@ -0,0 +1,56 @@
+## ADDED Requirements
+
+### Requirement: Platform authentication sessions are implemented
+The platform SHALL expose login, registration, logout, and current-user routes backed by platform-owned user records and in-memory session tokens.
+
+#### Scenario: Active user logs in
+- **WHEN** a client posts a valid account and password to `POST /api/v1/auth/login`
+- **THEN** the platform MUST return `200` with an authenticated `AuthSessionResponse` and a session token
+
+#### Scenario: Pending user cannot log in
+- **WHEN** a pending user submits valid credentials
+- **THEN** the platform MUST reject the login with `403` and MUST NOT issue a session token
+
+#### Scenario: Current user is requested
+- **WHEN** a client sends `GET /api/v1/users/current` with a valid bearer session token
+- **THEN** the platform MUST return the bounded current user DTO without password material
+
+#### Scenario: Session logs out
+- **WHEN** a client posts to `POST /api/v1/auth/logout` with a valid bearer token
+- **THEN** the platform MUST invalidate that session token
+
+### Requirement: Registration is low privilege by default
+Public registration SHALL create pending users with server scope and SHALL NOT grant platform administrator privileges.
+
+#### Scenario: Visitor registers
+- **WHEN** a visitor submits display name, email, and password to `POST /api/v1/auth/register`
+- **THEN** the platform MUST create a pending user with a non-platform-admin role and return `status=pending`
+
+### Requirement: User management updates are supported
+The platform SHALL support controlled user updates through `PUT /api/v1/users/{id}` using named DTOs and service validation.
+
+#### Scenario: User status is updated
+- **WHEN** a platform client sends a valid status update for an existing user
+- **THEN** the platform MUST persist and return the updated user DTO
+
+### Requirement: Current user preferences are supported
+The platform SHALL allow an authenticated current user to update bounded profile and theme preference fields.
+
+#### Scenario: Current user profile is updated
+- **WHEN** a client sends `PUT /api/v1/users/current/profile` with a valid bearer session token
+- **THEN** the platform MUST persist the bounded profile fields and return the updated current user DTO
+
+#### Scenario: Current user theme is updated
+- **WHEN** a client sends `PUT /api/v1/users/current/theme` with a valid bearer session token
+- **THEN** the platform MUST persist the theme preference and return a `UserThemePreferenceResponse`
+
+### Requirement: Frontend fallback cannot silently grant platform admin
+The frontend SHALL NOT persist a local platform administrator user as a fallback authentication path.
+
+#### Scenario: Auth API is unavailable
+- **WHEN** the auth API is unavailable and local fallback is not explicitly enabled
+- **THEN** the frontend MUST keep the user on the authentication screen and MUST NOT enter the console as platform administrator
+
+#### Scenario: Development fallback is enabled
+- **WHEN** local fallback is explicitly enabled
+- **THEN** the fallback user MUST have server-scoped access only and MUST NOT expose platform administrator navigation
@@ -0,0 +1,21 @@
+## 1. OpenSpec And Contracts
+
+- [x] 1.1 Add auth/session requirements covering login, registration, logout, current-user, profile/theme updates, user update, and local fallback limits.
+
+## 2. Platform Implementation
+
+- [x] 2.1 Extend user domain, DTO, model, validation, and service contracts for password hashes, profile, theme, and controlled user updates.
+- [x] 2.2 Implement in-memory platform auth sessions and route handlers for `/api/v1/auth/*` and `/api/v1/users/current*`.
+- [x] 2.3 Implement `PUT /api/v1/users/{id}` for the 用户管理 page.
+
+## 3. Frontend Implementation
+
+- [x] 3.1 Send bearer session tokens on API calls and persist only the API session token, not a privileged local user.
+- [x] 3.2 Gate local fallback behind an explicit dev/demo env flag and ensure fallback never grants platform administrator privileges.
+- [x] 3.3 Keep metrics/config/AI suggestion gaps in graceful page-local fallback behavior.
+
+## 4. Verification
+
+- [x] 4.1 Add backend API/service tests for login/register/current-user/logout/pending/disabled/user-update behavior.
+- [x] 4.2 Add frontend session tests for API login, failed auth, refresh session restoration, and fallback gating.
+- [x] 4.3 Run platform tests, platform_web tests/typecheck/build, `scripts/check-structure.sh`, and `openspec validate fix-platform-auth-session-api --strict`.