Fix für gemeldetes Problem: VanVans Code funktionierte nicht auf der Verwaltungsseite. Ursache
war ein dritter, komplett separater, gemeinsamer Code (6GAM4AST), den sich niemand gemerkt
hatte — VanVan gab stattdessen ihren normalen persönlichen Zugangscode ein, der dort aber nicht
galt. Jetzt auf ausdrücklichen Wunsch vereinheitlicht: die Verwaltungsseite prüft denselben
persönlichen Code wie der normale Seitenzugang (SITE_ACCESS_CODE_QCIGA/_VANVAN). Die tägliche
Neueingabe-Pflicht bleibt bestehen (eigene Sitzung mit 24h statt 90 Tagen Gültigkeit) — nur der
geprüfte Code ist jetzt kein separater dritter mehr. Das alte Secret VERWALTUNG_ACCESS_CODE wird
nicht mehr verwendet. Lokal mit wrangler pages dev end-to-end getestet (beide Codes + alter Code
korrekt abgelehnt).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch NUR diese eine Zugangsseite (öffentliche Startseite und die
eingeloggte Verwaltung selbst bleiben unangetastet): zwei groß und gegenläufig rotierende,
warm golden bzw. violett eingefärbte Van's-Logo-Wasserzeichen im gesamten Fensterhintergrund,
plus das echte Logo als sich drehendes "Siegel" im Kästchen mit pulsierendem Glanz-Kreis und
drei zeitversetzt aufblitzenden Funkel-Emojis. Ziel: die tägliche Pflicht-Eingabe soll Freude
machen statt trockene Sicherheitsabfrage zu sein. Alle Animationen respektieren weiterhin
prefers-reduced-motion. Reine Design-Änderung, Formular-/Auth-Logik unverändert.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Technisches Accessibility-Audit ergab sechs behebbare Punkte, alle jetzt gefixt:
- Skip-to-Content-Link ganz oben auf jeder Seite (WCAG 2.4.1)
- Fehler-/Statusmeldungen (Checkout, Login, Rezension, Gate-/Verwaltungs-Code) jetzt mit
role="alert"/aria-live, damit Screenreader sie automatisch ansagen (WCAG 4.1.3)
- Warenkorb-Icon hatte fälschlich das "Konto"-Label geerbt, sagt jetzt korrekt "Warenkorb"
(WCAG 4.1.2/2.4.4), dafür t.nav.cart in allen 4 Sprachen neu ergänzt
- Sichtbarer Fokus-Ring beim Mengenfeld auf der Produktseite wiederhergestellt (WCAG 2.4.7)
- Placeholder-only Formularfelder (Gate-Zugangscode, Verwaltungs-Suche/Filter/Tracking) haben
jetzt echte Labels (sichtbar per sr-only-Klasse oder aria-label) statt nur Platzhaltertext
(WCAG 1.3.1/3.3.2)
- Übersprungene Überschriften-Ebenen (h1→h3 ohne h2) in Checkout, Warenkorb, Kontakt, Konto
korrigiert (WCAG 1.3.1)
Reine Accessibility-Nachrüstung, keine funktionale Änderung. Kleinstunternehmer-Ausnahme
(§3 Abs.3 BFSG) greift hier vermutlich, aber vorsorglich sauber umgesetzt.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Der Name "Tages-Code" konnte fälschlich als sich täglich änderndem/rotierendem Code
verstanden werden. Tatsächlich bleibt der Code dauerhaft gleich (6GAM4AST) — nur die
24h-Sitzung läuft ab, wodurch derselbe Code einmal pro Tag erneut eingegeben werden
muss. Reine Text-/Kommentar-Korrektur, keine Verhaltensänderung.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch: /verwaltung/ + /api/verwaltung/* verlangen jetzt ZUSÄTZLICH zum
normalen 90-Tage-Seitenzugang einen zweiten, eigenen Code, den nur qciga und VanVan kennen —
und der nach 24 Stunden automatisch abläuft (muss also einmal täglich neu eingegeben werden).
Der Rest der Seite ist davon unberührt, nur die Bestellübersicht ist betroffen.
Bewusst als eigenständiges System (eigenes Cookie vandiy_verwaltung_session, eigenes Geheimnis
VERWALTUNG_SESSION_SECRET, eigener HMAC-Signaturcode statt geteiltem mit dem normalen
Seitenzugang) — gleiches Trennungsprinzip wie bei den Kundenkonten: ein Leck bei einer
Sitzungsart darf nie die andere gefährden.
Neue Dateien: functions/_shared/verwaltung-auth.js (Session-Logik), public/verwaltung-code.html
(Eingabemaske im selben Stil wie die Haupt-Zugangsseite). functions/_middleware.js prüft nach
erfolgreicher Haupt-Sitzung zusätzlich diese zweite Sitzung für /verwaltung*-Pfade. Beide
API-Routen (orders.js, orders/[id].js) prüfen die zweite Schranke zusätzlich eigenständig,
nach demselben Verteidigungs-in-der-Tiefe-Prinzip wie die bestehende Haupt-Prüfung.
Lokal vollständig durchgetestet (wrangler pages dev): kompletter Ablauf ohne jeden Zugang ->
Haupt-Gate -> Redirect zum Tages-Code -> falscher Code abgelehnt -> richtiger Code setzt
24-Stunden-Cookie -> Seite und API danach erreichbar. Bestätigt: der Rest der Seite bleibt
unberührt (kein Tages-Code nötig), UND dass VanVan mit nur dem Haupt-Zugang (ohne Tages-Code)
ebenfalls noch ausgesperrt bleibt, wie gewünscht.
Zwei neue Cloudflare-Secrets in Produktion gesetzt: VERWALTUNG_SESSION_SECRET (zufällig
erzeugt) und VERWALTUNG_ACCESS_CODE (der eigentliche Tages-Code, an qciga und VanVan zu
verteilen).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
