Fehler wie refresh_token_not_found, refresh_token_already_used und AuthSessionMissingError werden serverseitig als unauthenticated behandelt (statt als Hard-Error).
Stale sb-* Session-Cookies werden aktiv bereinigt.
Middleware fuehrt fuer /api/* keinen separaten Supabase-Auth-Call mehr aus, damit keine doppelten Refresh-Versuche entstehen.
Die eigentliche API-Authentifizierung bleibt in den Route-Handlern unveraendert aktiv.
Ein ungültiger oder abgelaufener x-tenant-id Header wird mit 403 beantwortet (kein stiller Fallback auf einen anderen Tenant).
Frontend-Verhalten (ADR-PS-322):
apiFetch validiert den gespeicherten Tenant-Kontext vor dem Senden.
Bei tenant-spezifischem 403 wird für idempotente Methoden (GET/HEAD/OPTIONS) einmal ohne x-tenant-id wiederholt.
Nicht-idempotente Requests (POST/PUT/PATCH/DELETE) werden nicht automatisch wiederholt.
System-Admins werden im Portal-Layout nicht mehr zwangsweise auf die Admin-Subdomain umgeleitet (ADR-PS-325); API-Tenant-Guards bleiben unverändert strikt.
Tenant-gebundene Views sollen Requests erst senden, wenn ein Property-/Tenant-Kontext vorhanden ist (z. B. Apartments-Liste, ADR-PS-326), um erwartbare 403-Loops im Leerlauf zu vermeiden.
Aktive + historische SupportAccessRequests (30 Tage) fuer den aktuellen Mandanten. History-Quelle ist SupportAccessRequest (nicht TenantMember). Die Grantor-Anzeige im Admin wird ueber supportAccessGrantedByName aus decidedBy aufgeloest. Mit aktivem SYSTEM_SUPPORT-Grant bleibt der Supporter im gewaehrten Tenant voll operativ und kann diese Historie dort ebenfalls einsehen.
/api/tenant/support-access/[requestId]/revoke
POST
SupportAccessRequest widerrufen. Cascade: DATA_VIEW-Widerruf entzieht auch TENANT_ACCESS. Ein aktiver SYSTEM_SUPPORT-Benutzer im gewaehrten Tenant kann denselben Lifecycle ebenfalls beenden. Audit-Log SUPPORT_ACCESS_REVOKED.
/api/cron/cleanup-support-access
POST
Cron-Job: setzt abgelaufene GRANTED-Requests auf EXPIRED, entfernt/entzieht abgelaufene SYSTEM_SUPPORT-Berechtigungen in TenantMember, bereinigt support-gebundene Legacy-Memberships (supportAccessRequestId) und schreibt eine interne Ticket-Protokollnotiz bei Auto-Expiry.
DSGVO-Maskierung: Ohne aktiven Support-Zugang werden personenbezogene Daten (E-Mail, Name) in allen Admin-API-Responses maskiert. In der globalen Benutzerliste (/api/admin/users ohne tenantId-Filter) sind PII immer maskiert.
Meldet “Auto weggefahren” oder “Abgeschleppt” und setzt den entsprechenden Abschlussstatus
/api/inquiries/[id]/towing
POST
Startet den Abschleppprozess (Haftungsflow)
/api/inquiries/[id]/warn
POST
Legacy-Endpunkt für Warnhinweis; nicht Teil des aktuellen Portal-Detailflows
/api/inquiries/respond
POST
Auf Anfrage antworten (Ja/Nein/Veto)
/api/messages
GET/POST
Nachrichten
/api/messages/[id]
GET
Einzelne Nachricht
/api/notifications
GET
System-Benachrichtigungen
Inquiry-Lifecycle: Ein abgelaufenes PENDING wird auf REJECTED gesetzt (eskalierbar), nicht automatisch geschlossen. Closing erfolgt erst durch aktive Aktion (report-vehicle-removed oder abgeschlossener Towing-Flow).
Mandantendetails inkl. Mitgliederliste und PII-Maskierung via aktivem SupportAccessRequest. supportAccessGrantedByName zeigt den echten Grantor (decidedBy), nicht den Support-Antragsteller.
Geschuetzte Subdomains (Portal, Admin, Go) verwenden ein Auth-First Pattern: Unauthentifizierte Requests auf beliebige Pfade erhalten einen HTTP 307 Redirect zur Login-Seite – nicht 404. Dies ist ein Sicherheitsprinzip, das verhindert, dass Applikationsstruktur an unauthentifizierte Nutzer preisgegeben wird.
Alle Marketing-Seiten (www) verwenden NextSeo fuer OpenGraph und Twitter Meta-Tags:
Default-Konfiguration in next-seo.config.ts (og:type, og:locale, og:siteName, og:image /icons/icon-512.png 512x512, Twitter summary_large_image). Fallback-Rewrites fuer /images/og-image.jpg und /images/og-image.png in next.config.mjs (ADR-PS-265/269).
Per-Page Overrides mit <NextSeo openGraph=\{\{...\}\} /> fuer Titel, Beschreibung und Canonical-URL.
Language-Alternates (DE, EN, FR, IT) fuer internationale SEO.
SSR-Rendering: OG- und Twitter-Meta-Tags werden server-seitig im initialen HTML gerendert, sodass Crawler (Google, Facebook, Twitter, LinkedIn) und Tools wie curl korrekte Vorschauen erhalten (ADR-PS-254).
4 themenspezifische SEO-Landingpages fuer den CH-Markt:
URL
Hauptkeyword
Slug
/parkraummanagement-wohnanlagen
Parkraummanagement Wohnanlagen
parkraummanagement
/besucherparkplaetze-verwalten
Besucherparkplaetze verwalten
besucherparkplaetze
/falschparker-loesen
Falschparker loesen
falschparker
/parkplatz-software-schweiz
Parkplatz-Software Schweiz
parkplatzSoftware
Jede Seite hat: Hero, Problem (mit Bullet-Points), Solution, Benefits Grid (6 Cards), USP-Highlight (Bewohner-Crowdsourcing), Social Proof, FAQ (5 Fragen, JSON-LD FAQPage Schema), CTA, Related Topics. Alle Texte in DE/EN/FR/IT via src/locales/*/seoLanding.ts. Wiederverwendbares Layout: src/components/marketing/landing/SeoLandingPage.tsx.
SSR-Architektur (ADR-PS-270): Content wird server-seitig via getSeoLandingData() in getServerSideProps aufgeloest und als typisierte Props an die Komponenten uebergeben. Dadurch enthaelt der initiale HTML-Response den vollstaendigen Content (800+ Woerter), korrekte JSON-LD Schemas (SoftwareApplication + FAQPage) und Meta-Tags mit echten Texten – wichtig fuer Crawler (Google, Facebook, etc.). Die Komponenten nutzen kein useTranslation() fuer SEO-Inhalte.