Commit Graph
7 Commits
Author SHA1 Message Date
qciganoandClaude Sonnet 5 bf0d169015 Echtes Google-/PayPal-Login: OAuth 2.0 + PKCE, eigene Kundendatenbank, DSGVO-Selbstbedienung
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]>
2026-08-04 01:45:55 +02:00
qciganoandClaude Sonnet 5 81c175d03c Zahlungsarten überarbeitet: echtes PayPal, Klarna & eigene Kartenmaske raus
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]>
2026-08-04 01:06:41 +02:00
qciganoandClaude Sonnet 5 5df0643a9d Fix: Bestell-E-Mail wird jetzt zuverlässig verschickt (await statt waitUntil)
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]>
2026-08-03 22:48:45 +02:00
qciganoandClaude Sonnet 5 af729ba571 Gutscheine "nur einmal pro Person" + Bestell-E-Mail-Benachrichtigung
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]>
2026-08-03 22:16:38 +02:00
qciganoandClaude Sonnet 5 fb7a7b76c2 Echtes Bestellsystem: Cloudflare D1 statt Beispieldaten in der Verwaltung
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]>
2026-08-03 20:32:46 +02:00
qciganoandClaude Sonnet 5 d3efaf8aba Interne Bestellverwaltung mit Status-Übersicht + Auswertung (/verwaltung/)
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]>
2026-08-03 19:27:21 +02:00
qciganoandClaude Sonnet 5 ad07584906 Eigene Zugangscode-Schranke statt Cloudflare Access — löst VanVans Login-Problem
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]>
2026-08-03 18:55:44 +02:00