clemensandClaude Sonnet 5
d642814fb5
app/stripe.php: minimaler REST-Client fuer die Stripe-API auf Basis von PHP-Streams statt eines vendorten SDKs - diese PHP-Installation hat keine curl-Extension, Streams sind zudem portabler und brauchen kein composer.json. - Fuer jeden bezahlten Tarif per API ein Stripe-Produkt mit monatlichem Preis angelegt, referenziert ueber einen stabilen lookup_key statt hartcodierter Price-ID; Erstellung ist idempotent. - abo-upgrade.php: erstellt eine Stripe-Checkout-Session fuer den gewaehlten Tarif, tenant_id/plan_code als Metadaten auf Session UND Subscription (damit spaetere Subscription-Events zuordenbar bleiben). - abo-portal.php: oeffnet das Stripe Customer Portal fuer bestehende Kunden (Zahlungsmittel/Kuendigung, ohne eigene UI dafuer). - stripe-webhook.php: verifiziert die Stripe-Signature per HMAC-SHA256 mit Zeitstempel-Toleranz, verarbeitet checkout.session.completed, customer.subscription.updated/.deleted, invoice.paid/.payment_failed und haelt tenant_billing aktuell. Bewusst kein CSRF-/Login-Check (Stripe ruft unauthentifiziert auf), stattdessen ausschliesslich Signaturpruefung als Echtheitsnachweis. - mandant-einstellungen.php: echter "Jetzt upgraden"-Button (Stripe Checkout) sowie "Zahlungsmethode verwalten/Abo kuendigen" (Customer Portal), sobald ein Stripe-Kunde existiert. Live getestet (Stripe-Testmodus, kein echtes Geld): voller Checkout-Flow bis zum echten Redirect auf checkout.stripe.com, Webhook-Verarbeitung durch selbst erzeugte, korrekt signierte Test-Events (da diese Dev-Umgebung keine oeffentlich erreichbare URL fuer echte Stripe- Zustellung hat) inklusive Ablehnung falscher Signaturen, Customer Portal mit echtem per API angelegtem Test-Kunden. Alle Regressionstests weiterhin gruen (36 Seiten HTTP-Smoke, Golden Master, M8-Isolation/ Rollenmatrix). Noch offen: echten Webhook-Endpunkt auf die Produktions-Domain eintragen, sobald diese feststeht; Wechsel auf Live-Keys; Dolibarr-Sync (Phase 3). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kaffeeliste
Dieses Repository enthält den laufenden Umbau der Kaffeelisten-App von einer Windows/IIS/LDAP-gebundenen Legacy-App zu einer mehrkundenfähigen SaaS- Anwendung. Der Umbau erfolgt schrittweise im selben Repository, nicht in einem getrennten Zielverzeichnis: Legacy-Seiten und neue SaaS-Bausteine liegen nebeneinander, bis eine Seite vollständig auf das neue Modell umgestellt ist.
Den vollständigen Plan mit Zielbild, Datenmodell, Rollenmodell und
Meilensteinen beschreibt docs/saas-umstrukturierungsplan.md. Der
Fortschritt je Meilenstein steht in docs/m2-technical-foundation.md bis
docs/m5-app-kern.md.
Struktur
- Legacy- und SaaS-Seiten liegen als flache PHP-Dateien im Webroot, zum
Beispiel
index.php,stricheintragen.php,kaffeeliste.php,mitarbeiterverwalten.php. app/: zentrale Bausteine für Bootstrap, DB-Zugriff, Auth, Mail und das neue Ledger-Modell (app/ledger.php).database/migrations/: versionierte Schemaänderungen, anzuwenden überscripts/migrate.php.scripts/: Migrations-, Backfill- und Prüfskripte (Golden Master, HTTP-Smoke, M3/M4-Checks).docs/: Planungs- und Meilensteindokumentation.
Umgang mit Legacy-Seiten
- Seiten, die noch direkt auf
kl_*-Tabellen schreiben, werden schrittweise auf tenant-sicheres Lesen/Schreiben überapp/ledger.phpundapp/saas-auth.phpumgestellt; siehe die Meilensteindokumente für den aktuellen Stand je Seite. - Neue Produktfunktionen entstehen gegen das neue Modell (Tenants, Users,
Participants, Ledger), nicht mehr direkt gegen die
kl_*-Tabellen. - Lokale Entwicklung gegen MySQL ist in
docs/dev-mysql.mdbeschrieben.