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.
**PHASE_7_SUMMARY.md**
High-level overview des gesamten Phase 7 Implementation
- Was wurde implementiert
- Deliverables Übersicht
- Security Features
- Code Statistics
- Tested Features
- Deployment Readiness
- User Experience Impact
- Integration mit bestehenden Features
- Checklisten für Production
- Support & Maintenance Guide
**Zielgruppe:** Project Manager, Tech Lead, DevOps
**Länge:** ~400 Zeilen
**Format:** Markdown mit Tables und Checklisten
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
**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>
- VERSION in install.sh wird jetzt aus Git-Tags gelesen
- Format: git describe --tags --always
- Beispiel: v0.2.0 → zeigt VERSION=0.2.0 im Script
- Fallback auf 'dev' wenn keine Tags vorhanden
Vorteil: Version wird automatisch aktualisiert, keine manuelle Änderung nötig
- Neue .env Variable: CONTAINER_CREATE_TIMEOUT=10 (Sekunden)
- Frontend: Automatische Retries bei fehlgeschlagener Verifizierung
- Max 5 Versuche mit 2 Sekunden Delay zwischen Versuchen
- Gesamtzeit begrenzt auf 10 Sekunden (CONTAINER_CREATE_TIMEOUT)
- Bessere Fehlermeldungen für Timeout-Situation
Behebt Problem dass Verifizierung multiple 400-Fehler zeigt bevor sie funktioniert.
Dies passiert weil Container beim Spawn noch nicht bereit ist.
Mit Retries warten wir jetzt automatisch bis Container ready ist (max 10 Sek).
- Ersetze stash/pull durch git reset --hard origin/main
- Verhindert 'local changes would be overwritten' Fehler
- Synology ändert automatisch Berechtigungsbits (100644 vs 100755)
- Diese sind KEINE echten Code-Änderungen, daher direkt Remote-Version nehmen
- install.sh läuft jetzt vollautomatisch ohne Fehler
- Neuer Endpoint: POST /api/admin/config/reload
- Nur für Admins zugänglich
- Lädt .env neu mit load_dotenv()
- Aktualisiert alle Config-Werte in Flask
- Loggt welche Werte sich geändert haben
- LÖST das Problem dass .env Änderungen sonst Neustart brauchten
Verwendung:
curl -X POST http://localhost:5000/api/admin/config/reload -H "Authorization: Bearer $JWT_TOKEN"
Statt:
docker-compose down && docker-compose up -d
- container_manager.py: Pre-Check vor containers.run() hinzufügen
- Prüfe ob Container bereits existiert (z.B. nach Fehler)
- Wenn running: Wiederverwenden statt zu erstellen
- Wenn stopped: Versuchen zu starten oder zu löschen
- Verhindert Docker 409 Conflict-Fehler
- api.py: Container-Spawn Fehlerbehandlung verbessern
- Container-Spawn ist optional beim Signup
- User wird trotzdem erstellt wenn Spawn fehlschlägt
- JWT wird immer returned (Status 200)
- docs/BUGFIX_CONTAINER_SPAWN.md: Dokumentation hinzufügen
- Erklär die Probleme, Fixes und Testing
CRITICAL FIX for container routing bug:
- Replace all spawn_container() calls with spawn_multi_container()
- spawn_container() was overwriting primary container ID with single ID
- This caused all containers to route to same container-id
- Now each container_type gets its own route:
- spawner.wieland.org/slug-template-01
- spawner.wieland.org/slug-template-02
- spawner.wieland.org/slug-template-next
- Affects: Signup, Login, Container Restart endpoints
- Fixes: #CONTAINER-ROUTING
- Clarify that install.sh only builds .env-defined templates
- Add emphasis: without .env entry, templates are NOT built
- Update section 1.3 to explain .env configuration requirement
- Change from 'automatically builds all' to 'only builds defined templates'
- Update overview to clarify that only .env-defined templates are built
- Update architecture diagram to reflect new .env-based process
- Add new 'Template Build-Prozess' section with detailed explanation
- Update 'Automatisiertes Deployment' with correct .env-based instructions
- Add emphasis to WICHTIG notes about .env configuration
- Update quick-start guide to show .env configuration as first step
- Update checklist to highlight critical .env step
- Clarify validation, error handling, and fallback behavior
- Read USER_TEMPLATE_IMAGES from .env to determine which templates to build
- Parse semicolon-separated template list and extract image names with tags
- Only build templates defined in .env, not all user-template-* directories
- Validate that template directories and Dockerfiles exist
- Warn when template is defined but directory/Dockerfile missing
- Warn about unused template directories not in USER_TEMPLATE_IMAGES
- Fallback to old logic (build all) when USER_TEMPLATE_IMAGES undefined
- Maintains backward compatibility with existing installations
- Improves .env.example with better documentation and examples
Integrate shadcn sidebar component into dashboard layout:
- Create new dashboard/layout.tsx with SidebarProvider and responsive design
- Add AppSidebar component with navigation items (Dashboard, Settings, Admin)
- Implement responsive sidebar (permanent on desktop, drawer on mobile)
- Add Settings page with user profile information
- Update dashboard page to remove old header and integrate with new layout
- Configure Tailwind CSS colors for sidebar theming
- Add components.json for shadcn configuration
Features:
- Desktop sidebar is permanent and collapsible
- Mobile sidebar opens as overlay/drawer
- Active route highlighting in navigation
- User profile display with email and role
- Logout button in sidebar footer
- Conditional Admin link (only for admin users)
- Settings page showing account information
Files created:
- src/components/ui/sidebar.tsx (shadcn sidebar primitives)
- src/components/app-sidebar.tsx (main sidebar component)
- src/app/dashboard/layout.tsx (layout wrapper)
- src/app/dashboard/settings/page.tsx (settings page)
- components.json (shadcn configuration)
Files modified:
- tailwind.config.ts (added sidebar color scheme)
- src/app/globals.css (added sidebar CSS variables)
- src/app/dashboard/page.tsx (refactored to work with layout)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Full guide for creating custom user templates
- Step-by-step instructions with requirements
- 3 complete examples: Python Flask, Hugo static site, Node.js with DB
- Deployment workflows for local and production
- Troubleshooting section and best practices
- Quick reference and checklist
Debug API now supports 'list-users' action to view all registered users
without needing JWT authentication. Useful for quick debugging via
X-Debug-Token header.
When user tries to signup with an already registered email, the system
now sends a login link instead of showing an error. This improves UX and
prevents user enumeration attacks. The response message is identical for
both new registrations and existing emails.
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
- Add rotating file handler to app.py for logging to /app/logs/spawner.log
- Configure max 10MB per file with 5 backup files
- Update admin_api.py debug endpoint to read from Flask log file
- Implement clear-logs functionality to truncate log file
- Update documentation with Flask log file details
- Creates log directory automatically if missing
- Updated clear-logs to inform that docker logs cannot be deleted
- Updated documentation to reflect docker-based log reading
- No log file needed anymore"
- Move template loading after class definition to avoid NameError
- Initialize TEMPLATE_IMAGES, TEMPLATES_CONFIG, and CONTAINER_TEMPLATES after Config class
- Use simple loop instead of calling static methods during class init
- Prevents 'Config is not defined' errors during import
This fixes the circular dependency issue where _build_container_templates()
was trying to reference Config.TEMPLATE_IMAGES while the class was still
being defined.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Fix USER_TEMPLATE_IMAGES quoting in .env.example (prevent bash metacharacter issues)
- Add all SMTP configuration variables to docker-compose environment
- Add EMAIL service variables (FRONTEND_URL, MAGIC_LINK_EXPIRY, RATE_LIMIT)
- Add JWT and resource limit variables
- Improve environment variable organization with comments
SMTP variables were defined in .env but not passed to container, causing
email service configuration issues.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
The install.sh script was only building user-template-next when
USER_TEMPLATE_IMAGE=user-template-next:latest was set in .env, which
was an old single-container configuration.
Changes:
- Remove dependency on USER_TEMPLATE_IMAGE for building user-template-next
- Always build user-template-next when directory exists
- Add user-template-next to TOTAL_BUILDS count automatically
- Change user-template-next build from optional warning to required
- Update build output to clearly show multi-container template building
- Update final installation summary to show template configuration
This ensures both dev and prod templates are always built for the
Multi-Container MVP, regardless of legacy .env settings.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Add step-by-step deployment instructions covering:
- Phase 1: Preparation (clean slate, build templates, configure env)
- Phase 2: Start services (docker-compose up, health checks)
- Phase 3: First registration (test user creation)
- Phase 4: Test both containers (dev and prod)
Includes:
- Verification checklist for backend, frontend, docker, traefik
- Detailed troubleshooting guide for common issues
- Monitoring and status commands
- Security checklist for production
- Performance scaling recommendations
- Next phase features for enhancement
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
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>
- Use npm ci only if package-lock.json exists
- Falls back to npm install if not present
- Allows flexible package installation without strict lockfile requirement
