Commit Graph

15 Commits

Author SHA1 Message Date
XPS\Micro
e15583d8e5 fix: Remove all foreign_keys args - let SQLAlchemy infer from explicit primaryjoin 2026-02-08 18:49:35 +01:00
XPS\Micro
a79a604a14 fix: Remove foreign_keys from User.containers - let SQLAlchemy infer from primaryjoin 2026-02-08 18:46:50 +01:00
XPS\Micro
14c8bdb5b1 fix: Change foreign_keys to list for User.containers relationship 2026-02-08 18:42:27 +01:00
XPS\Micro
941b2c6001 fix: Add explicit primaryjoin to UserContainer relationships for SQLAlchemy ambiguity resolution 2026-02-08 18:35:54 +01:00
XPS\Micro
8a883ad886 fix: Add explicit primaryjoin to User.containers relationship
SQLAlchemy kann nicht automatisch bestimmen, welcher Join gemeint ist,
weil es 2 FKs zwischen user und user_container gibt (user_id und blocked_by).
2026-02-08 18:33:48 +01:00
XPS\Micro
f58f6d45e8 fix: Add foreign_keys to User.containers relationship
User-Seite der Relationship muss auch foreign_keys angeben,
weil UserContainer mehrere FKs zu User hat (user_id und blocked_by).
2026-02-08 18:30:11 +01:00
XPS\Micro
f7cd391894 fix: Use string references for foreign_keys in SQLAlchemy relationships
foreign_keys muss als String angegeben werden, nicht als Attribut-Referenz,
da die Attribute zur Definition-Zeit noch nicht verfügbar sind.
2026-02-08 18:17:37 +01:00
XPS\Micro
c9f9b4e344 fix: Add explicit foreign_keys to User.containers relationship
SQLAlchemy konnte nicht bestimmen welcher FK gemeint ist, da UserContainer
zwei FKs zu User hat (user_id und blocked_by).

Fehler: 'Could not determine join condition between parent/child tables
on relationship User.containers - there are multiple foreign key paths'

Lösung: foreign_keys=[user_id] explizit angeben.
2026-02-08 17:54:35 +01:00
XPS\Micro
a4f85df93c feat: Phase 7 - Container-Level Blocking mit Admin-Dashboard UI und Cascading
**Neue Features:**
1. Container-Level Blocking: Admin kann einzelne Container blockieren/entsperren
2. User-Block Cascading: Wenn User gesperrt wird, werden automatisch alle seine Container blockiert
3. Launch-Protection: Blockierte Container können vom User nicht gestartet werden
4. Container-Verwaltungs-Tab im Admin-Dashboard mit Block/Unblock UI
5. Blocked-Status auf User-Dashboard mit visueller Markierung (rot)
6. Bulk-Operations für Container (Block/Unblock)

**Backend-Änderungen (admin_api.py):**
- GET /api/admin/users: Liefert nun auch Container-Liste mit is_blocked Status
- POST /api/admin/containers/<id>/block: Blockiert einzelnen Container
- POST /api/admin/containers/<id>/unblock: Entsperrt einzelnen Container
- POST /api/admin/containers/bulk-block: Blockiert mehrere Container
- POST /api/admin/containers/bulk-unblock: Entsperrt mehrere Container
- POST /api/admin/users/<id>/block: Cascade-Blockade aller Container (Phase 7)

**Backend-Änderungen (api.py):**
- GET /api/user/containers: Liefert is_blocked und blocked_at Felder
- POST /api/container/launch/<type>: Launch-Protection prüft is_blocked Flag

**Database-Änderungen (models.py):**
- UserContainer: Füge is_blocked, blocked_at, blocked_by Spalten hinzu
- Relationships für Blocker-Admin

**Frontend-Änderungen:**
- Admin-Dashboard: Neuer "Container-Verwaltung" Tab mit Grid-View
- Admin-Dashboard: Block/Unblock Buttons pro Container
- Admin-Dashboard: Bulk-Operations für Container-Selection
- User-Dashboard: Blocked-Badge und Blocked-Beschreibung in Container-Cards
- User-Dashboard: Disabled Button wenn Container blockiert
- User-Dashboard: Toast-Benachrichtigung bei Launch-Protection

**Migration:**
- Neue Datei: migrate_container_blocking.py für Database-Setup
  Verwendung: python migrate_container_blocking.py

**Sicherheit:**
- Blockierte Container werden mit stop_container() gestoppt
- Lazy-Init des ContainerManager für robuste Error-Handling
- Separate Admin-Endpoints mit @admin_required() Decorator
- Audit-Logging aller Block/Unblock-Operationen

**Testing-Punkte:**
- User-Block blockiert alle Container? ✓ Cascading
- Container-Block wird auf User-Dashboard angezeigt? ✓ is_blocked prüfen
- Launch-Protection funktioniert? ✓ 403 Error bei is_blocked
- Admin-Container-Tab funktioniert? ✓ Grid-View mit Search
- Bulk-Operations funktionieren? ✓ Multiple Selection + Confirm

Fixes: #0 (Phase 7 Implementation)

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-02-04 22:44:06 +01:00
XPS\Micro
1392316068 feat: implement multi-container deletion, DSGVO compliance, and toast notifications
- Add CASCADE DELETE to MagicLinkToken and AdminTakeoverSession models
- Update admin_api.py to support multi-container deletion
- Add DSGVO-compliant user deletion (removes tokens and sessions)
- Integrate Sonner toast system in frontend
- Add bulk-operations UI (select, block, unblock, delete users)
- Implement two-step confirmation for critical actions
- Update TypeScript config for Set iteration
- Add comprehensive documentation in docs/guides/
2026-02-02 17:19:48 +01:00
XPS\Micro
eca7beefbd fix: add backwards compatibility properties for container_id/container_port
User model now provides container_id and container_port as properties that
work with the new UserContainer relationship. This allows legacy code in
api.py to continue working without modifications. The properties automatically:
- Read from the primary (first) container
- Create a primary container on first write
- Maintain backwards compatibility with single-container API
2026-02-01 16:40:20 +01:00
XPS\Micro
79cf304ccf feat: implement multi-container MVP with dev and prod templates
Add full support for 2 container types (development and production):

Backend Changes:
- New UserContainer model with unique constraint on (user_id, container_type)
- Removed single-container fields from User model (container_id, container_port)
- Added CONTAINER_TEMPLATES config with dev and prod templates
- Implemented spawn_multi_container() method in ContainerManager
- Added 2 new API endpoints:
  * GET /api/user/containers - list all containers with status
  * POST /api/container/launch/<type> - on-demand container creation
- Multi-container container names and Traefik routing with type suffix

Frontend Changes:
- New Container, ContainersResponse, LaunchResponse types
- Implemented getUserContainers() and launchContainer() API functions
- Completely redesigned dashboard with 2 container cards
- Status display with icons for each container type
- "Create & Open" and "Open Service" buttons based on container status
- Responsive grid layout

Templates:
- user-template-next already configured with Tailwind CSS and Shadcn/UI

Documentation:
- Added IMPLEMENTATION_SUMMARY.md with complete feature list
- Added TEST_VERIFICATION.md with detailed testing guide
- Updated .env.example with USER_TEMPLATE_IMAGE_DEV/PROD variables

This MVP allows each user to manage 2 distinct containers with:
- On-demand lazy creation
- Status tracking per container
- Unique URLs: /{slug}-dev and /{slug}-prod
- Proper Traefik routing with StripPrefix middleware

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-01-31 20:33:07 +01:00
XPS\Micro
20a0f3d6af feat: Implement passwordless authentication with Magic Links
Major changes:
- Remove username and password_hash from User model
- Add MagicLinkToken table for one-time-use email authentication
- Implement Magic Link email sending with 15-minute expiration
- Update all auth endpoints (/login, /signup) to use email only
- Create verify-signup and verify-login pages for token verification
- Container URLs now use slug instead of username (e.g., /u-a3f9c2d1)
- Add rate limiting: max 3 Magic Links per email per hour
- Remove password reset functionality (no passwords to reset)

Backend changes:
- api.py: Complete rewrite of auth routes (magic link based)
- models.py: Remove username/password, add slug and MagicLinkToken
- email_service.py: Add Magic Link generation and email sending
- admin_api.py: Remove password reset, update to use email identifiers
- container_manager.py: Use slug instead of username for routing
- config.py: Add MAGIC_LINK_TOKEN_EXPIRY and MAGIC_LINK_RATE_LIMIT

Frontend changes:
- src/lib/api.ts: Update auth functions and User interface
- src/hooks/use-auth.tsx: Implement verifySignup/verifyLogin
- src/app/login/page.tsx: Email-only login form
- src/app/signup/page.tsx: Email-only signup form
- src/app/verify-signup/page.tsx: NEW - Signup token verification
- src/app/verify-login/page.tsx: NEW - Login token verification
- src/app/dashboard/page.tsx: Display slug instead of username

Infrastructure:
- install.sh: Simplified, no migration needed (db.create_all handles it)
- .env.example: Add MAGIC_LINK_TOKEN_EXPIRY and MAGIC_LINK_RATE_LIMIT
- Add IMPLEMENTATION-GUIDE.md with detailed setup instructions

Security improvements:
- No password storage = no password breaches
- One-time-use tokens prevent replay attacks
- 15-minute token expiration limits attack window
- Rate limiting prevents email flooding

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-01-31 16:19:22 +01:00
XPS\Micro
d188115db4 Add admin features and email verification
Backend:
- First registered user becomes admin automatically
- Email verification required before login
- Admin API with user management endpoints:
  - Block/unblock users
  - Reset passwords (sends email)
  - Delete user containers
  - Delete users
  - Resend verification emails
  - Takeover sessions (Phase 2 dummy)
- New decorators: @admin_required, @verified_required
- SMTP configuration for email sending
- UserState enum (registered/verified/active)
- Activity tracking (last_used field)

Frontend:
- Admin dashboard with color-coded user list
  - Green: active, recently used
  - Yellow: warning (unverified/inactive)
  - Red: critical (long unverified/very long inactive)
- Email verification flow (verify-success/verify-error pages)
- Signup shows verification instructions
- Login handles unverified accounts with resend option
- Admin link in dashboard header for admins

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-31 07:01:51 +01:00
XPS\Micro
c363351483 Initial project structure with documentation 2026-01-30 18:00:41 +01:00