Migration: Sensible Daten nicht mehr in URLs übergeben

Übersicht, welche Frontend-Requests aktuell E-Mail/Device-ID oder ähnliche Daten in der URL transportieren, und wie der Server erweitert werden muss, um Header-basierte Varianten sauber zu bedienen.

Betroffene Frontend-Stellen (URL mit Nutzerdaten)

• frontend/src/services/dataservice.js
checkConditions(email, deviceId) → GET check-conditions/:email/:deviceId
• frontend/src/services/userDataLoader.js
loadProfileData → GET muc4taxiActivateUser/:email (per apiFetch, mit Auth-Headern, aber E-Mail steckt in der URL)
• frontend/src/Components/Profil.svelte
getActualUserFromDb → GET ${API_PREFIX}/muc4taxiActivateUser/:email (plain fetch, ohne Auth-Header)
  markInvoicesAsSeen → POST /invoices/mark-seen (E-Mail im Body, ok)
• frontend/src/services/invoiceService.js
getUnseenInvoices(email) → GET invoices/unseen?email=...
fetchInvoicesForEmail(email) → GET invoices?email=... (alle Varianten)
  markInvoicesSeen(email) → POST body (ok)
• Admin-Bereich (weniger kritisch, aber ebenfalls Query-Params mit Mails):
  frontend/src/Components/AdminArea/InvoiceProcessing.svelte → GET invoices/history?adminEmail=..., invoices/pending-users?adminEmail=...
frontend/src/Components/AdminArea/FeatureFeedback.svelte → GET feature-feedback/summary?adminEmail=...

Zielbild Frontend (Header statt URL-Params)

• E-Mail und Device-ID per Header schicken:
  • x-user-email: E-Mail des eingeloggten Nutzers/Admins
  • x-device-id: Geräte-ID/Fingerprint
• Für Such-/Filter-Parameter, die nicht identifizierend sind, können Query-Params bleiben.

Erforderliche Server-Erweiterungen

check-conditions

• Aktuell nur Legacy-Route /:email/:deviceId.
• Ergänzen: router.get("/") (ggf. mit membershipMiddleware o.ä.), liest req.headers["x-user-email"] und req.headers["x-device-id"], ruft denselben Controller (getConditions) auf. Legacy-Route kann vorerst bestehen bleiben.

muc4taxiActivateUser

• Aktuell GET /:email.
• Ergänzen: GET / (oder "/me") mit x-user-email/x-device-id aus den Headers; Controller nutzt Header statt req.params.email. Legacy-Param-Route als Fallback belassen.

invoices (user-seitig)

• GET invoices/unseen?email=... und invoices?email=... auf Header umstellen:
  • Neue Routenvarianten ohne Query, lesen x-user-email (Device-ID optional, falls Membership geprüft werden soll).
  • Query-Param-Variante vorerst als Fallback akzeptieren, bis Frontend umgestellt ist.
• POST invoices/mark-seen kann E-Mail weiter im Body haben; optional: wenn Body fehlt, E-Mail aus Header ziehen.

Admin-spezifische Endpoints mit adminEmail in Query

• feature-feedback/summary, invoices/history, invoices/pending-users etc.: Header x-user-email (Admin) akzeptieren und optional Query behalten, bis Frontend umgestellt ist.

Empfohlene Migrationsschritte

1. Server zuerst erweitern

   • Neue Header-basierte GETs für check-conditions und muc4taxiActivateUser.
   • In den Controller-Funktionen: Wenn req.params fehlen, auf req.headers["x-user-email"] / req.headers["x-device-id"] ausweichen.
   • Invoice-/Admin-Endpoints: Header akzeptieren, Query weiter tolerieren.

2. Frontend umstellen

   • checkConditions in dataservice.js: auf apiFetch("check-conditions", { headers: { "x-user-email": email, "x-device-id": deviceId } }).
   • loadProfileData / Profil.svelte: muc4taxiActivateUser ohne E-Mail in der URL, E-Mail per Header.
   • invoiceService: invoices/unseen und invoices ohne ?email=, stattdessen Header; mark-seen kann so bleiben.
   • Admin-Requests (feature-feedback/summary, invoices/history, pending-users): adminEmail per Header senden.

3. Übergangsphase

   • Legacy-Routen/Querys vorerst beibehalten, aber deprecate.
   • Logging/Monitoring: Header-basierte Pfade nutzen, 404/405 auf alten Pfaden beobachten.

4. Aufräumen

   • Nach Umstellung Query/Param-Varianten entfernen.
   • CORS-Allowed-Headers prüfen: x-user-email, x-device-id sind bereits whitelisted in server/config/config.js.

Rückfragen / offene Punkte

• Soll die Membership-Middleware auch für check-conditions/muc4taxiActivateUser greifen (Header-Variante)? Falls ja, Middleware vor den neuen Routen platzieren.
• Dürfen Admin-Endpoints komplett auf Header-only umgestellt werden oder Query-Fallback behalten?