karim
0daf6c393d
feat(backup): Konzept (BACKUP.md) + backups-Datenmodell (0004)
...
Backup-Übersicht/Restore bewusst NICHT als Fake-UI gebaut — im Mock gäbe es
keine echten Kundendaten. Stattdessen:
- 0004_backups.sql: Register-Tabelle (Metadaten: instance/account, trigger,
status, storage_key, size, sha256, Zeitstempel). Dump-Dateien liegen extern.
- BACKUP.md: Konzept für Modell A (studio-bezogener Export statt Full-Dump),
Erzeugung (pg_dump/cron/Storage/Rotation), Restore-Sicherheitsregeln,
geplante API. Bau der Logik, sobald echtes Provisioning steht.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com >
2026-05-31 13:09:53 +02:00
karim
540dd9df5b
refactor(admin): separates Admin-Login statt is_admin-Flag
...
Auf Wunsch: Betreiber-Bereich getrennt von Kundenkonten.
- auth.js: signAdminToken (role:operator), requireAdmin prüft Token-Rolle;
requireAuth weist Operator-Token ab (saubere Trennung beide Richtungen)
- routes/admin.js: POST /admin/login (ADMIN_PASSWORD → Operator-Token)
- env.js: adminPassword statt adminEmail
- 0003_admin.sql: droppt die nicht mehr genutzte accounts.is_admin-Spalte
- register/login/account/me: is_admin restlos entfernt
E2E: Kunde→403, falsches PW→401, richtiges PW→Token, stats→200,
Admin-Token→Kundenroute→401.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com >
2026-05-31 10:43:47 +02:00
karim
6a2393301d
feat(admin): Betreiber-Panel (/api/admin) mit is_admin-Flag
...
- 0003_admin.sql: accounts.is_admin
- auth.js: ensureAdminFlag (Konto = ADMIN_EMAIL wird auto-promoted),
is_admin im JWT, requireAdmin-Middleware (prüft DB autoritativ)
- routes/admin.js: GET /stats (Kunden/Abos/Instanzen/MRR), GET /accounts,
GET /accounts/:id/instances, POST /instances/:id/{suspend,reactivate}
- register/login + /account/me liefern is_admin
- ADMIN_EMAIL in .env.example
E2E: Admin-Promotion, Kunde→403, Stats (2 Kunden/MRR 49), Kundenliste.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com >
2026-05-31 00:04:19 +02:00
karim
7e38fc68bd
feat(account): Profil-Felder, Instanz-Liste, Profil-Update + Passwort ändern
...
- 0002_account_profile.sql: company/contact_name/adresse/phone + instances.label
- GET /account/me: alle Profilfelder + instances[] (Multi-Instanz vorbereitet),
instance einzeln bleibt rückwärtskompatibel
- PATCH /account/me: Profil aktualisieren (Whitelist)
- POST /account/password: Passwort ändern (prüft aktuelles PW → 403 sonst)
E2E verifiziert: Profil speichern, PW-Wechsel (falsch=403/richtig=200),
instances[]=1 nach Checkout.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com >
2026-05-30 23:57:17 +02:00
karim
6290475ea3
Initial: RAPPORT-HOST Iteration 1 (proprietär)
...
Kommerzielle Hosting-/Abo-Plattform für Rapport-Instanzen.
- React-Frontend (Vite/JSX): Landing, Register, Login, Plans, Dashboard
- Node/Express-Backend: Auth (bcrypt+JWT), Stripe-Billing, Provisioning
- HOST-Postgres-Schema: accounts, subscriptions, instances
- Provisioning-Interface + Modell-A-Adapter (Studio im geteilten Stack)
- MOCK-Modus: voller End-to-End-Flow ohne Stripe/Rapport-Stack testbar
- Idempotentes Fulfillment (Upsert auf stripe_subscription_id)
- docker-compose für lokale host-db; identisch auf Hetzner deploybar
E2E lokal verifiziert: Register -> Checkout(mock) -> Instanz -> Idempotenz.
Lizenz: proprietär (kein AGPL-Code eingebunden, nur Netzwerk-API zur Familie).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com >
2026-05-30 15:37:33 +02:00
karim