- qciga-Fenster zeigt jetzt Dogi (Name + echtes Foto) statt Icon-Platzhalter — Rolle/Code-Prüfung
im Hintergrund bleibt unverändert "qciga" (nur die Anzeige wurde umbenannt).
- VanVan-Fenster bekommt ein neues, eigenes Foto für die Zugangsseite.
- Beide Quellfotos (~1,8 MB PNG) auf 400×400 zugeschnitten (gesichtsfokussiert) und als WebP
komprimiert (7–14 KB) — eigene Dateien nur für diese Seite, NICHT die sitehweit verwendete
öffentliche vanvan-portrait.png ersetzt oder angetastet.
- Schlüssel-Emoji im Dogi-Button durch 🩵 (Baby-Blau-Herz) ersetzt, passend zur Cyan-Akzentfarbe
seines Fensters.
- functions/_middleware.js: alte Freigabe von /img/vanvan-portrait.png entfernt, stattdessen
gezielt nur die zwei neuen Avatar-Dateien freigegeben (kein Shop-/Kundendatum).
Per Build + wrangler pages dev + Browsertest verifiziert: beide Avatare laden korrekt (200),
alte Foto-Freigabe korrekt entfernt (wieder 302), Layout/Funktion unverändert intakt.
Auf ausdrücklichen Wunsch im Stil einer bereits bestehenden Zwei-Personen-Zugangsseite umgebaut,
aber komplett an Van's eigene Marke angepasst (Farben/Schrift/Wasserzeichen unverändert: Lila/
Anthrazit/Hellblau/Gold statt fremder Projektfarben). Jede Person bekommt ihr eigenes Fenster mit
Avatar (VanVan: ihr echtes Porträtfoto; qciga: passendes Icon, da noch kein Foto in diesem Projekt
hinterlegt ist), eigenem Codefeld und eigenem "Öffnen"-Button in unterschiedlicher Akzentfarbe
(Cyan/Violett für qciga, Gold/Violett für VanVan). Technisch unverändert: /gate-auth erkennt die
Rolle weiterhin selbst anhand des eingegebenen Codes, unabhängig vom benutzten Fenster.
Dabei gefundener und behobener Bug: /img/vanvan-portrait.png wurde von der Zugangs-Schranke selbst
blockiert (302) — das für den Avatar gebrauchte Foto zeigte deshalb nur einen leeren Kreis. Gezielt
nur diese eine Datei freigegeben (kein Shop-/Kundendatum, ohnehin VanVans öffentliches Porträtfoto).
Per echtem Browsertest verifiziert: beide Fenster funktional getrennt (falscher Code im einen
Fenster zeigt den Fehler nur dort, richtiger Code im anderen Fenster loggt korrekt ein), Layout auf
Desktop nebeneinander und auf schmalen Bildschirmen sauber gestapelt.
Neues Kästchen "🔥 Nur Bestseller (Top 6)" im Shop-Filter (alle 4 Sprachen) — zeigt beim Anhaken
genau die 6 Produkte mit den meisten echten Verkäufen. Keine manuelle Pflege nötig: neuer
öffentlicher Endpunkt GET /api/bestseller berechnet die Rangliste live per SQL-Aggregation aus
den echten Bestelldaten (order_items JOIN orders, GROUP BY Produkt-Slug, SUM der Menge), NICHT
die manuell im Admin-Bereich setzbare "Bestseller"-Auszeichnung.
Zählweise: stornierte und noch nicht bezahlte (zahlungOffen) Bestellungen zählen nicht mit (sonst
würden Fehlbestellungen/nie eingegangene Zahlungen die Rangliste verfälschen), ebenso wenig
kostenlose Positionen wie der Abo-Teddy (kein echtes Kaufinteresse). Liefert ausschließlich
Produkt-Slugs zurück, keinerlei Bestell-/Kundendaten — bleiben weiterhin nur in /api/verwaltung/*.
Verifiziert: SQL-Aggregation mit Testdaten geprüft (korrekte Rangfolge, korrekter Ausschluss von
storniert/zahlungOffen/gratis, LIMIT 6 exakt). Frontend-Verdrahtung (Checkbox -> fetch -> Filter)
per echtem Browsertest mit vorgetäuschter API-Antwort bestätigt (checken zeigt genau die
vorgegebenen Produkte, abwählen zeigt wieder alle).
Neuer Endpunkt POST /gate-logout (functions/_middleware.js) löscht alle drei Zugangs-Cookies auf
einmal (normale 90-Tage-Sitzung, Rollen-Anzeige, tägliche Verwaltungs-Sitzung) — "abmelden"
bedeutet also wirklich abmelden von allem, nicht nur einen Teil der Schranke offen lassen. Button
im selben "besonderen" Look wie die Hero-Kiste darunter (wandernder Verlaufsrand in den drei
Markenfarben + Funkeln) statt eines schlichten Standard-Buttons.
Per curl (Cookie-Löschung + anschließende 302-Sperre auf /verwaltung/ und /) und per echtem
Browser-Klicktest (Playwright) end-to-end verifiziert.
Live per Browsertest gefunden: Auf /admin/ (das die Haupt-Schranke bewusst umgeht) versucht ein
eigenes Skript, den Service Worker unter /sw.js zu registrieren (für die "Installieren"-Funktion) —
das schlug mit einem echten Browserfehler fehl ("script resource is behind a redirect"), weil
/sw.js und /manifest.webmanifest bisher nicht auf der Liste öffentlich erreichbarer Dateien standen
und deshalb selbst einen 302 auf die Zugangscode-Seite bekamen. Betrifft jeden Aufruf von /admin/
ohne aktive Haupt-Gate-Sitzung (z.B. direkt per Lesezeichen). Beide Dateien enthalten keinerlei
Shop-/Kundendaten (reines Caching-Skript bzw. App-Metadaten), Freigabe also unbedenklich — vor der
Änderung geprüft, dass wirklich nichts Sensibles drin steht.
Bisher hätte SITE_PUBLIC=true (gedacht für den Go-Live der eigenen Domain) versehentlich auch die
interne *.pages.dev-Werkstatt-Adresse für jede/n im Internet geöffnet, weil die Middleware nur den
Pfad, nie den aufgerufenen Hostnamen geprüft hat. Jetzt hart anhand des Hostnamens geprüft: nur ein
Hostname außerhalb von *.pages.dev darf durch SITE_PUBLIC öffentlich werden. Per wrangler pages dev
mit Host-Header-Overrides verifiziert (pages.dev -> weiterhin 302 Gate-Redirect, andere Domain -> 200).
Nebenbei: totes, seit 04.08.2026 ungenutztes Secret VERWALTUNG_ACCESS_CODE live + lokal entfernt
(Code prüft seitdem denselben Zugangscode wie der normale Seitenzugang), sowie zwei veraltete
Kommentare bereinigt, die noch auf die längst entfernte Seite /demo-abo/ verwiesen.
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]>
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]>
Impressum, Datenschutz, AGB, Widerruf und Muster-Widerrufsformular liegen jetzt vor der
Zugangsschranke. Grund: PayPal prueft vor der Freischaltung von "Log in with PayPal" die
angegebene Datenschutz- und AGB-Adresse tatsaechlich nach — hinter der Schranke haette deren
Pruefteam nur die Code-Eingabe gesehen und die Freischaltung waere gescheitert. Google verlangt
beim Veroeffentlichen ebenfalls eine erreichbare Datenschutzerklaerung. Rechtlich ist das
ohnehin die saubere Seite; diese Seiten enthalten keine Shop- oder Kundendaten.
Bewusst eng gefasst: feste Liste der fuenf Seiten (kein Praefix-Match), dazu nur Stylesheets
und Logo/Favicons, damit die Seiten beim Pruefteam gestaltet ankommen. Die JS-Buendel aus
/_astro/ bleiben gesperrt — darin stecken u.a. die Produktdaten.
Lokal geprueft: die fuenf Rechtstexte + CSS + Logo liefern 200, waehrend Startseite, Shop,
Warenkorb, Checkout, Konto, Verwaltung, Produktseiten und alle JS-Buendel weiterhin auf die
Zugangscode-Seite umleiten und /api/verwaltung/ weiterhin 401 liefert.
Co-Authored-By: Claude Opus 5 <[email protected]>
Kundenkonten sind jetzt genauso echt wie die PayPal-Zahlung: server-geprüftes OAuth 2.0 mit
PKCE für Google und "Log in with PayPal" (functions/_shared/oauth.js, oauth-handlers.js),
neue D1-Tabelle "customers" (bewusst ohne Passwort-Feld), eigene von der Zugangscode-Schranke
getrennte Sitzungs-Logik (customer-auth.js). Echte DSGVO-Rechte direkt im Kontobereich:
Daten herunterladen (Art. 15/20) und Konto unwiderruflich löschen (Art. 17), Bestellungen
bleiben aus gesetzlichen Gründen erhalten. Datenschutzerklärung entsprechend ergänzt.
Ohne echte Google-/PayPal-Zugangsdaten zeigt der Login-Button ehrlich einen
"noch nicht eingerichtet"-Hinweis statt eine Anmeldung vorzutäuschen.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch, mit Fokus auf rechtliche Absicherung:
- Klarna komplett entfernt (hätte eigene Händlerprüfung + Bonitätsprüfungs-
Pflichten nach der neuen EU-Verbraucherkreditrichtlinie vorausgesetzt).
- Eigene Kreditkarten-Eingabemaske komplett entfernt (wäre PCI-DSS-pflichtig
gewesen — für einen kleinen Shop praktisch nicht stemmbar). Kartenzahlung
bleibt möglich: PayPals eigener, PCI-zertifizierter Gast-Checkout bietet
Kredit-/Debitkarte an, ohne dass Kartendaten je unsere Seite berühren.
- PayPal ist jetzt ECHT server-seitig verifiziert statt dem Browser blind zu
vertrauen: eigener Cloudflare-Function-Flow (functions/_shared/paypal.js +
functions/api/paypal/) legt die PayPal-Bestellung server-seitig an, zieht
die Zahlung nach Bestätigung server-seitig ein und prüft den eingezogenen
Betrag gegen die Bestellsumme — die Bestellung wird ausschließlich bei
bestätigter, betragsgleicher Zahlung angelegt. /api/orders lehnt direkte
PayPal-Bestellungen jetzt ausdrücklich ab (verhindert vorgetäuschte
"bezahlte" Bestellungen ohne echte Zahlung).
- Neuer, ehrlicherer Bestellstatus "zahlungOffen": Überweisungs-Bestellungen
starten jetzt so (Geld noch nicht da) statt fälschlich sofort "bezahlt" zu
heißen — Schutz vor Warenversand, bevor das Geld wirklich angekommen ist.
Eigene Kachel/Filter/Badge-Farbe in der Verwaltung, Umsatz-/Auswertungs-
Zahlen zählen "zahlungOffen" bewusst nicht mit.
- Rechtstexte (AGB, Datenschutzerklärung, FAQ, Versand & Zahlung) auf allen
4 Sprachen aktualisiert: nur noch PayPal + Überweisung erwähnt, inkl. DSGVO-
Hinweis zur internationalen Datenübertragung an PayPal (Data Privacy
Framework-Zertifizierung).
- D1-Migration 0003: neue Spalte paypal_order_id (Zahlungsbeleg) + erweiterter
Status-Wertebereich, auf Live-Datenbank angewendet, bestehende Daten intakt.
Mit echten Testbestellungen lokal verifiziert: Überweisung legt korrekt
"zahlungOffen" an, direkter PayPal-Bypass-Versuch an /api/orders wird
abgelehnt, PayPal-Route meldet sauber "noch nicht eingerichtet" ohne
Zugangsdaten. Checkout-UI zeigt nur noch 2 Zahlungsarten, Bestellknopf ist bei
PayPal ausgeblendet (Zahlung läuft exklusiv über den echten PayPal-Button).
Für den echten Zahlungseingang fehlt noch VanVans eigenes PayPal-Business-
Konto (Client-ID + Secret) — Details in der Vault-Dokumentation.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
context.waitUntil() lief in dieser Pages-Functions-Umgebung nicht zuverlässig zu
Ende, bevor die Anfrage beendet wurde - Bestellungen wurden korrekt gespeichert,
aber die Benachrichtigungs-Mail an [email protected] kam nie an.
Mit echten Live-Bestellungen verifiziert: mit waitUntil kam nichts bei Resend an,
mit await kam die Mail sofort und zuverlässig an.
Außerdem: "Auf Lager"-Feld im Produkt-Formular (Admin) steht jetzt über "Kategorie"
statt darunter, wie gewünscht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
1) Gutscheincodes können jetzt im Adminbereich auf "nur einmal pro Person einlösbar"
gestellt werden. Wird serverseitig durchgesetzt (neue Spalte orders.gutschein_code +
Prüfung in functions/api/orders.js gegen die echte Bestelldatenbank, case-insensitiv
nach E-Mail-Adresse) — kann also NICHT durch Löschen von localStorage/einen anderen
Browser umgangen werden, anders als die bisherige rein clientseitige Rabattlogik.
Stornierte Bestellungen zählen nicht als "schon benutzt". Ausführlich getestet: echter
Browser-Checkout mit Einmal-Code funktioniert beim ersten Versuch, wird beim zweiten
Versuch (gleiche E-Mail) korrekt mit klarer Fehlermeldung abgelehnt, mit anderer E-Mail
weiterhin nutzbar.
2) Bestell-E-Mail-Benachrichtigung an [email protected]: recherchiert und
vorbereitet (existierte vorher nirgends im Code). Läuft über Resend (kostenlos bis
3.000 E-Mails/Monat), im Hintergrund per context.waitUntil() nach jeder neuen
Bestellung — verzögert nie die Antwort an die Kundschaft und kann eine Bestellung
niemals zum Scheitern bringen, selbst wenn der Versand fehlschlägt (mit ungültigem
Testschlüssel verifiziert: Bestellung bleibt trotzdem erfolgreich gespeichert). Wird
automatisch aktiv, sobald ein RESEND_API_KEY als Secret hinterlegt wird.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Ersetzt die Phase-1-Beispieldaten in /verwaltung/ durch ein echtes, funktionierendes
Bestellsystem:
- Neue D1-Datenbank (vans-diy-bastelbedarf-db) mit orders/order_items-Tabellen,
an das Pages-Projekt gebunden (wrangler.toml).
- Neue API-Routen (Pages Functions): POST /api/orders legt beim Checkout eine echte
Bestellung an (mit Validierung); GET/PATCH /api/verwaltung/orders(/:id) listen bzw.
ändern Bestellungen — beide zusätzlich zur Middleware nochmal eigenständig gegen die
Zugangscode-Sitzung geprüft (Verteidigung in der Tiefe). Gemeinsame Auth-Logik aus
_middleware.js nach functions/_shared/auth.js ausgelagert.
- Checkout (4 Sprachen) sendet beim Absenden die echte Bestellung an die API, zeigt bei
einem Fehler eine klare Meldung statt einfach auf die Danke-Seite weiterzuleiten.
- /verwaltung/ lädt Bestellungen jetzt live per fetch(), mit Lade-/Fehlerzustand, und
erlaubt direktes Ändern des Bestellstatus per Dropdown (sofort in der Datenbank
gespeichert). Neuer Status "storniert" (zählt nicht in Umsatz/Auswertung mit).
Vollständig lokal end-to-end getestet (wrangler pages dev + lokale D1): echter
Browser-Checkout -> Bestellung landet in der Datenbank -> erscheint sofort in der
Verwaltung -> Status ändern bleibt nach Neuladen bestehen.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Neue Seite, dauerhaft nur für qciga/vanvan sichtbar (functions/_middleware.js
schützt /verwaltung/* jetzt IMMER — unabhängig vom SITE_PUBLIC-Schalter, mit
dem der Rest der Seite später öffentlich geschaltet wird):
- Status-Kacheln: Offen / In Bearbeitung / Versendet / Abgeschlossen (klickbar
als Filter) + Gesamtumsatz-Kachel
- Filterbare Bestellliste (nutzt dieselben Status-Badges/-Farben wie die
Kunden-Kontoseite)
- Auswertung "Meistverkaufte Produkte je Kategorie" (Balken nach verkaufter
Menge, aus den echten Produktdaten berechnet)
- Auswertung "Bestellungen nach Land" (DE/AT/CH/LU, Balken + Prozent)
Wie an anderer Stelle im Projekt: es gibt noch keine echte, geräteüber-
greifende Bestell-Datenbank (Phase 1) — die Seite zeigt realistische
Beispieldaten in exakt der Struktur, die echte Bestellungen später haben
werden (Cloudflare Worker + D1), klar als solche gekennzeichnet.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Ersetzt die (fehlerhaft auf die GANZE Domain wirkende) Cloudflare-Zero-
Trust-Access-Sperre durch eine eigene, schlanke Lösung nach dem bewährten
Vorbild von "Dogfather Universe": eine Pages-Functions-Middleware
(functions/_middleware.js) prüft bei jeder Anfrage ein HMAC-signiertes
Session-Cookie; ohne gültiges Cookie geht's zu public/gate.html (im Van's-
Design), wo ein Zugangscode eingegeben wird. Zwei getrennte Codes für qciga
und VanVan, 90 Tage gültig, danach neu eingeben. /admin/* ist komplett
ausgenommen — läuft weiter über das echte GitHub-OAuth-Login, das für
VanVan schon funktioniert.
Bonus: die drei separaten Vorschau-Seiten (demo-normal/demo-konto/demo-abo)
sind jetzt überflüssig und entfernt. Stattdessen gibt's ein schwebendes
Umschalter-Widget (Layout.astro), das NUR sichtbar ist, wenn das Gate-Cookie
vorhanden ist (also nur für uns beide) — auf jeder beliebigen Seite kann
per Knopfdruck zwischen "Normaler Besucher", "Angemeldete Kundin" und
"Abonnentin" gewechselt werden, ohne die Seite verlassen zu müssen.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
qcigano