Projektnotizen – Stand /api/v3

MUC4TAXI Web-App & Server

• Status: Frontend und Backend sind vollständig auf /api/v3 umgestellt. Altes /api liefert 426 + Update-Seite, sodass Legacy-Clients nicht mehr weiterarbeiten können.
• Authentifizierung: Alle relevanten Endpunkte (Flugplan, Rechnungen, usw.) prüfen x-user-email + Geräte-Fingerprint und blockieren bei Ungültigkeit. Damit bleibt das „ein Benutzer, ein Gerät“-Prinzip bestehen.
• PWA/Service Worker: Workbox-Setup erkennt Legacy-Responses und zwingt ein Update. Builds setzen NODE_ENV=production, wodurch Redux & Co. ohne Warnungen laufen.
• Deployment-Test: Kopiere frontend/dist nach server/public, starte den Server (NODE_ENV=production node server.js). Auf http://localhost:5500 lädt dann exakt das Produktivbundle.

Geplanter Marktplatz (Auktionen/Kleinanzeigen)

Ziel: Eigene Anwendung, aber nur für verifizierte MUC4TAXI-Nutzer zugänglich. Anforderungen:

1. Gemeinsame Auth-Zwänge
   • Genau ein Gerät pro Benutzer, gleiche Fingerprint-Logik wie in der Haupt-App.
   • Keine parallelen Sessions: wenn der Benutzer bereits im Marktplatz aktiv ist, weitere Logins blockieren oder aktiv abmelden.
2. Zugriffskonzept
   • Interner Link innerhalb der MUC4TAXI-App (z. B. „Zum Marktplatz“), der ein signiertes Token erstellt (HMAC/JWT mit E-Mail, Gerät, Ablaufzeit).
   • Ziel-Anwendung validiert das Token gegen den MUC4TAXI-Server oder prüft über einen /api/v3/market/auth-Endpoint die Berechtigung.
   • Optional zusätzliche Header (x-device-id, x-user-email) mitsenden, damit der Marktplatz-Server die gleiche Logik nutzen kann.
3. Server-Architektur
   • Entweder eigener Service mit Frontend (z. B. SvelteKit/Vite) oder Integration im bestehenden Repo als separate Route (/marktplatz), die nur nach Token-Validierung lädt.
   • Datenbankmodell für Listings (User-ID, Titel, Preis, Bilder, Ablaufdatum, Kategorie) + Moderations-Flags.
4. API-Scopes
   • GET /market/listings – unterstützt Filter, Pagination, Volltextsuche.
   • POST /market/listings – nur für verifizierte Benutzer (ggf. Rate-Limits).
   • PUT/DELETE /market/listings/:id – nur Eigentümer oder Admin.
5. Security
   • Tokens kurzlebig (z. B. 15 Minuten) + Refresh über Haupt-App.
   • CSRF verhindern (JWT im Header, nicht in Cookies).
   • Logging: klar erkennbare Herkunft (User + Device), damit Missbrauch auffällt.

Offene Punkte / Fragen

• server/kontroll.md: Diese Datei lag bereits im Repo, bevor ich angefangen habe. Inhalt ist offenbar ein internes Kontroll-/Changelog-Dokument; ich habe sie nicht erzeugt, aber auf Wunsch kann man sie aktualisieren oder entfernen.
• Marktplatz-Backend: Es existieren aktuell keine /api/v3/market/*-Routen. Die Frontend-Komponenten (ListingCards etc.) greifen ins Leere, solange kein Serverteil geschrieben ist.

Nächste Schritte (Vorschlag)

1. Marktplatz-API spezifizieren (Schema, Auth-Mechanismus, Endpoints).
2. Separates Repo oder neues Verzeichnis (marketplace-server, marketplace-frontend) anlegen, damit die Haupt-App schlank bleibt.
3. Token-Brücke bauen: /api/v3/market/token erstellt ein signiertes Login-Ticket und leitet den Benutzer weiter.
4. Tests & Monitoring: analog zum Hauptsystem (Vitest/Playwright + Healthcheck).

Damit bleibt die MUC4TAXI-App stabil, und der Marktplatz kann unabhängig, aber mit denselben Sicherheitsanforderungen umgesetzt werden.