clemens/kaffeekasse-saas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Deutsche Umlaute in UI und Dokumentation korrigieren

Browse Source
This commit is contained in:
clemens
2026-07-14 22:11:33 +02:00
parent f9544f24fd
commit 539117b409
31 changed files with 561 additions and 564 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/m0/README.md
+18 -18
View File
@@ -3,7 +3,7 @@
Stand: 2026-07-11
M0 dokumentiert den aktuellen Legacy-Bestand, bevor die SaaS-Umstrukturierung
beginnt. Ziel ist eine belastbare Ausgangsbasis fuer Migration, Sicherheit,
beginnt. Ziel ist eine belastbare Ausgangsbasis für Migration, Sicherheit,
Design-Erhalt und fachliche Vergleichstests.
## Status
@@ -13,24 +13,24 @@ Design-Erhalt und fachliche Vergleichstests.
| Code-Inventar | begonnen | Siehe `code-inventory.md` |
| Prozesslandkarte | begonnen | In `code-inventory.md` enthalten |
| Sicherheitsbaseline | begonnen | Siehe `security-baseline.md` |
| DB-Schema-Export | nicht aus Alt-DB verfuegbar | Siehe `legacy-db-status.md` |
| Golden-Master-Auswertungen | nicht aus Alt-DB verfuegbar | Siehe `legacy-db-status.md` |
| DB-Schema-Export | nicht aus Alt-DB verfügbar | Siehe `legacy-db-status.md` |
| Golden-Master-Auswertungen | nicht aus Alt-DB verfügbar | Siehe `legacy-db-status.md` |
| Design-/Screenshot-Referenz | teilweise geliefert | Siehe `screenshot-checklist.md` |
## Lokal abgeschlossen
- Legacy-Einstiegspunkte und Kernseiten identifiziert.
- Fachliche Tabellen aus SQL-Strings abgeleitet.
- Schreibende Aktionen und kritische Datenfluesse markiert.
- Sicherheitsrisiken fuer M0 inventarisiert.
- SQL-Vorlagen fuer Schema- und Golden-Master-Export angelegt.
- Screenshot-Checkliste fuer Design-Erhalt angelegt.
- Schreibende Aktionen und kritische Datenflüsse markiert.
- Sicherheitsrisiken für M0 inventarisiert.
- SQL-Vorlagen für Schema- und Golden-Master-Export angelegt.
- Screenshot-Checkliste für Design-Erhalt angelegt.
- Erste Screenshot-Referenzen unter `docs/m0/screenshots/` abgelegt.
- Festgelegt: Ein alter MS-SQL-Datenbankstand steht aktuell nicht zur
Verfuegung; M0 arbeitet deshalb mit Code, Screenshots und rekonstruierter
Verfügung; M0 arbeitet deshalb mit Code, Screenshots und rekonstruierter
MySQL-Dev-Datenbank als Ausgangsbasis.
## Lokale Einschraenkungen
## Lokale Einschränkungen
- `php` ist in dieser Umgebung nicht im PATH, daher kein lokaler Syntaxcheck und
kein lokaler App-Start.
@@ -40,33 +40,33 @@ Design-Erhalt und fachliche Vergleichstests.
## Blockiert bis Input vorliegt
Diese Punkte kann ich ohne externe Informationen nicht abschliessen:
Diese Punkte kann ich ohne externe Informationen nicht abschließen:
1. Falls spaeter doch noch ein MS-SQL-Dump auftaucht: Schema und
Golden-Master-Werte nachtraeglich exportieren.
1. Falls später doch noch ein MS-SQL-Dump auftaucht: Schema und
Golden-Master-Werte nachträglich exportieren.
2. MySQL-Dev-Schema als neue rekonstruierte Baseline weiter verifizieren.
3. Fehlende Screenshot-Zustaende nachreichen oder bewusst als optional markieren.
3. Fehlende Screenshot-Zustände nachreichen oder bewusst als optional markieren.
4. Produktivumgebung dokumentieren: PHP-Version, Webserver, SQL-Server-Version,
Auth-Setup, Cron/Job-Ausfuehrung.
Auth-Setup, Cron/Job-Ausführung.
## Was ich von dir brauche
Falls ein alter MS-SQL-Stand spaeter noch auftaucht, bitte eines der folgenden
Falls ein alter MS-SQL-Stand später noch auftaucht, bitte eines der folgenden
Pakete bereitstellen:
- Idealerweise: einen anonymisierten SQL-Server-Schemaexport plus Rowcounts.
- Alternativ: Zugriffsdaten zu einer Test-/Staging-DB, nicht zu Produktion.
- Alternativ: die Ergebnisse aus `schema-export.sql` als CSV/Excel/Markdown.
Zusaetzlich hilfreich:
Zusätzlich hilfreich:
- Ein erreichbarer Test-Link zur bestehenden App oder Screenshots der Seiten aus
`screenshot-checklist.md`.
- Beispiel-Accounts oder Rollen fuer Admin und normales Mitglied, nur fuer eine
- Beispiel-Accounts oder Rollen für Admin und normales Mitglied, nur für eine
Testumgebung.
- Info, ob hart codierte Zugangsdaten aus Legacy-Skripten bereits rotiert wurden.
- Entscheidung, ob M1/M2 nativ in PHP oder mit Framework vorbereitet werden
sollen.
Bitte keine Produktivpasswoerter oder echten personenbezogenen Exportdaten in
Bitte keine Produktivpasswörter oder echten personenbezogenen Exportdaten in
das Repository legen.
docs/m0/code-inventory.md
+36 -36
View File
@@ -10,28 +10,28 @@ Das echte Datenbankschema muss noch mit `schema-export.sql` verifiziert werden.
| Datei | Rolle | Wichtige Beobachtung |
| --- | --- | --- |
| `config.php` | AD-/DB-Konfiguration | Erstellt globale SQL-Server-Verbindung `$conn` |
| `functions.php` | Auth-/User-Helper | Liest `$_SERVER['AUTH_USER']`, inkludiert LDAP, prueft `kl_Mitarbeiter` |
| `functions.php` | Auth-/User-Helper | Liest `$_SERVER['AUTH_USER']`, inkludiert LDAP, prüft `kl_Mitarbeiter` |
| `functionsLDAP.php` | LDAP-Mailauflösung | Ermittelt `$mailadress` aus AD |
| `header.php` | HTML-Head und Hinweisbanner | Laedt `assets/css/main.css`, liest `kl_hinweise` |
| `footer.php` | App-Sidebar und JS | Enthaelt die sichtbare Navigation und Admin-Menues |
| `header.php` | HTML-Head und Hinweisbanner | Lädt `assets/css/main.css`, liest `kl_hinweise` |
| `footer.php` | App-Sidebar und JS | Enthält die sichtbare Navigation und Admin-Menüs |
| `nav.php` | Navigation | Aktuell praktisch leer |
| `headerline.php` | Headerfragment | Enthaelt NUL-Zeichen, fachlich unklar |
| `assets/css/main.css` | Hauptdesign | HTML5-UP Editorial, gruener Akzent, Tabellen, Buttons, Sidebar |
| `headerline.php` | Headerfragment | Enthält NUL-Zeichen, fachlich unklar |
| `assets/css/main.css` | Hauptdesign | HTML5-UP Editorial, grüner Akzent, Tabellen, Buttons, Sidebar |
| `DataTables/` | Tabellen-Assets | Wird teilweise eingebunden, aber nicht konsequent initialisiert |
| `PHPMailer/` | Mailversand | Fuer Rundmails/Jahresauswertung genutzt |
| `TCPDF/` | PDF-Export | Fuer Kaffeelisten-Export genutzt |
| `PHPMailer/` | Mailversand | Für Rundmails/Jahresauswertung genutzt |
| `TCPDF/` | PDF-Export | Für Kaffeelisten-Export genutzt |
## Fachliche Kernseiten
| Datei | Prozess | Tabellen |
| --- | --- | --- |
| `index.php` | Persoenliches Dashboard, Saldo, Jahreswerte, eigene Striche, PayPal-Links | `kl_Mitarbeiter`, `kl_Einzahlungen`, `kl_Kaffeeverbrauch`, `kl_config` |
| `kaffeeliste.php` | Admin-Gesamtuebersicht mit Salden | `kl_Mitarbeiter`, `kl_Einzahlungen`, `kl_Kaffeeverbrauch` |
| `index.php` | Persönliches Dashboard, Saldo, Jahreswerte, eigene Striche, PayPal-Links | `kl_Mitarbeiter`, `kl_Einzahlungen`, `kl_Kaffeeverbrauch`, `kl_config` |
| `kaffeeliste.php` | Admin-Gesamtübersicht mit Salden | `kl_Mitarbeiter`, `kl_Einzahlungen`, `kl_Kaffeeverbrauch` |
| `stricheintragen.php` | Sammelerfassung von Strichen | `kl_Mitarbeiter`, `kl_Kaffeeverbrauch`, `kl_config` |
| `einzahlung.php` | Sammelerfassung von Einzahlungen | `kl_Mitarbeiter`, `kl_Einzahlungen`, `kl_Kaffeeverbrauch` |
| `mitarbeiterverwalten.php` | Mitglieder anlegen, bearbeiten, aktivieren, deaktivieren | `kl_Mitarbeiter` |
| `namenanpassen.php` | Anzeigenamen aendern | `kl_Mitarbeiter` |
| `letzteneintraege.php` | Letzte Buchungen anzeigen und loeschen | `kl_Einzahlungen`, `kl_Kaffeeverbrauch`, `kl_Mitarbeiter` |
| `namenanpassen.php` | Anzeigenamen ändern | `kl_Mitarbeiter` |
| `letzteneintraege.php` | Letzte Buchungen anzeigen und löschen | `kl_Einzahlungen`, `kl_Kaffeeverbrauch`, `kl_Mitarbeiter` |
| `csvupload.php` | Zahlungs-CSV importieren | `kl_Mitarbeiter`, `kl_Einzahlungen` |
| `exportKaffeeliste.php` | PDF-/Listenexport | `kl_Mitarbeiter`, `kl_Kaffeeverbrauch`, `kl_Einzahlungen`, `kl_config` |
| `mailausgebe.php` | Mailausgabe/Adressliste | `kl_Mitarbeiter` |
@@ -44,7 +44,7 @@ Das echte Datenbankschema muss noch mit `schema-export.sql` verifiziert werden.
## Abgeleitete Tabellen und Spalten
Diese Spalten sind aus dem Code abgeleitet und muessen mit dem echten DB-Schema
Diese Spalten sind aus dem Code abgeleitet und müssen mit dem echten DB-Schema
abgeglichen werden.
| Tabelle | Abgeleitete Spalten |
@@ -64,13 +64,13 @@ abgeglichen werden.
1. Seite inkludiert `functions.php`.
2. `functions.php` liest `$_SERVER['AUTH_USER']`.
3. `functionsLDAP.php` ermittelt Mailadresse aus LDAP.
4. Zugriff wird ueber `kl_Mitarbeiter.Email`, `aktiv` und `admin` geprueft.
4. Zugriff wird über `kl_Mitarbeiter.Email`, `aktiv` und `admin` geprüft.
M0-Feststellung:
Login-Konto, Kaffee-Teilnehmer und Rolle sind im Legacy-Modell gekoppelt. Fuer
SaaS muessen `users`, `participants` und `tenant_memberships` getrennt werden.
Login-Konto, Kaffee-Teilnehmer und Rolle sind im Legacy-Modell gekoppelt. Für
SaaS müssen `users`, `participants` und `tenant_memberships` getrennt werden.
### Persoenliches Dashboard
### Persönliches Dashboard
Quelle: `index.php`.
@@ -81,7 +81,7 @@ Berechnungen:
- Gesamtausgabe: Summe `kl_Kaffeeverbrauch.Kosten`.
- Gesamtstriche: Summe `kl_Kaffeeverbrauch.AnzahlStriche`.
- Aktueller Stand: Einzahlungen minus Ausgaben.
- Jahreswerte: dieselben Summen fuer aktuelles Jahr.
- Jahreswerte: dieselben Summen für aktuelles Jahr.
- Bei aktivem `strichperweb`: eigener Strich-Eintrag.
- Bei aktivem `paypaluse`: PayPal-Links anzeigen.
@@ -123,19 +123,19 @@ M0-Feststellung:
Das `admin`-Flag ist fachlich eine Rolleninformation und sollte in der SaaS-App
in `tenant_memberships.role` wandern.
### Korrektur letzter Eintraege
### Korrektur letzter Einträge
Quelle: `letzteneintraege.php`.
Aktionen:
- Letzte 100 Einzahlungen anzeigen.
- Einzahlung hart loeschen.
- Letzte 100 Strich-Eintraege anzeigen.
- Strich-Eintrag hart loeschen.
- Einzahlung hart löschen.
- Letzte 100 Strich-Einträge anzeigen.
- Strich-Eintrag hart löschen.
M0-Feststellung:
Finanznahe Korrekturen sollten im Zielmodell nicht hart loeschen, sondern als
Finanznahe Korrekturen sollten im Zielmodell nicht hart löschen, sondern als
Storno/Reversal mit Audit-Trail gespeichert werden.
### CSV-Import
@@ -148,8 +148,8 @@ Ablauf:
- CSV mit Komma-Trennung lesen.
- Name aus Spalte 3, Betrag aus Spalte 7, Datum aus Spalte 0.
- Mitarbeiter per Name oder `paypalname` finden.
- Dublette anhand Mitarbeiter, Betrag und Datumstag pruefen.
- Einzahlung einfuegen.
- Dublette anhand Mitarbeiter, Betrag und Datumstag prüfen.
- Einzahlung einfügen.
- Ergebnis in Erfolg/Fehler klassifizieren.
### Jahresauswertung
@@ -160,33 +160,33 @@ Ablauf:
- Gesamtstriche des aktuellen Jahres je aktivem Mitarbeiter berechnen.
- Konstante Anzahl neuer Striche/Gutschrift proportional verteilen.
- Einzahlung je Mitarbeiter einfuegen.
- Einzahlung je Mitarbeiter einfügen.
- Mail an Mitarbeiter senden.
M0-Feststellung:
Das ist ein Job/Skript mit direktem Schreibzugriff und Mailversand. Fuer SaaS
Das ist ein Job/Skript mit direktem Schreibzugriff und Mailversand. Für SaaS
braucht es Dry-Run, Audit, Tenant-Scope und expliziten Operator.
## Offene Schemafragen
- Gibt es Primary Keys, Foreign Keys und Indizes fuer die `kl_`-Tabellen?
- Sind Datentypen fuer Geldwerte `decimal`, `money`, `float` oder etwas anderes?
- Gibt es Primary Keys, Foreign Keys und Indizes für die `kl_`-Tabellen?
- Sind Datentypen für Geldwerte `decimal`, `money`, `float` oder etwas anderes?
- Gibt es historische Spalten, die im Code nicht sichtbar sind?
- Gibt es Trigger oder Stored Procedures?
- Gibt es weitere Jobs ausser `jahresauswertung.php`?
- Gibt es weitere Jobs außer `jahresauswertung.php`?
- Sind Umfragetabellen produktiv relevant oder Archiv/Randmodul?
## Technische Legacy-Inkonsistenzen
- `csvupload.php` sucht in `getMitarbeiterID` nach `Name = ? or paypalname = ?`,
uebergibt aber nur einen Parameter. Das sollte vor der Uebernahme des
übergibt aber nur einen Parameter. Das sollte vor der Übernahme des
CSV-Flows verifiziert werden.
- `einzahlung.php` prueft auf `$_GET["action"]`, die Buttons erzeugen aber
URLs mit `aktion=...`. Der Vorderseite-/Rueckseite-Filter kann dadurch
- `einzahlung.php` prüft auf `$_GET["action"]`, die Buttons erzeugen aber
URLs mit `aktion=...`. Der Vorderseite-/Rückseite-Filter kann dadurch
abweichend vom erwarteten Verhalten laufen.
- `exportKaffeeliste.php` referenziert `tcpdf/tcpdf.php`, waehrend der Ordner im
Repository `TCPDF/` heisst. Auf case-sensitiven Dateisystemen kann das
- `exportKaffeeliste.php` referenziert `tcpdf/tcpdf.php`, während der Ordner im
Repository `TCPDF/` heißt. Auf case-sensitiven Dateisystemen kann das
brechen.
- `headerline.php` ist fachlich leer beziehungsweise mit NUL-Zeichen gefuellt.
Vor der neuen App-Shell sollte geklaert werden, ob die Datei entfernt werden
- `headerline.php` ist fachlich leer beziehungsweise mit NUL-Zeichen gefüllt.
Vor der neuen App-Shell sollte geklärt werden, ob die Datei entfernt werden
kann.
docs/m0/golden-master-queries.sql
+5 -6
View File
@@ -3,10 +3,10 @@ M0 Golden-Master Queries
Ziel:
- Fachliche Legacy-Ergebnisse exportieren, damit Migration und neue SaaS-App
gegen denselben Stand verglichen werden koennen.
gegen denselben Stand verglichen werden können.
Ausfuehrung:
- In der Legacy-Datenbank ausfuehren.
Ausführung:
- In der Legacy-Datenbank ausführen.
- Ergebnisse je Query als CSV speichern.
- Keine personenbezogenen Exporte ins Repo committen.
*/
@@ -94,7 +94,7 @@ FROM kl_Einzahlungen e
JOIN kl_Mitarbeiter m ON m.MitarbeiterID = e.MitarbeiterID
ORDER BY e.Datum DESC, e.EinzahlungsID DESC;
-- 5. Letzte Strich-/Verbrauchseintraege je Teilnehmer
-- 5. Letzte Strich-/Verbrauchseinträge je Teilnehmer
SELECT
v.VerbrauchID,
v.MitarbeiterID,
@@ -142,7 +142,7 @@ GROUP BY m.MitarbeiterID, m.Name, m.Email
HAVING SUM(v.AnzahlStriche) >= 10
ORDER BY m.Name;
-- 9. 100-Tage-Rueckseite analog Legacy-Stricherfassung
-- 9. 100-Tage-Rückseite analog Legacy-Stricherfassung
SELECT
m.MitarbeiterID,
m.Name,
@@ -182,4 +182,3 @@ WHERE YEAR(v.Datum) = @CurrentYear
AND m.aktiv = 1
GROUP BY m.MitarbeiterID, m.Name, m.Email
ORDER BY GesamtStriche DESC, m.Name;
docs/m0/legacy-db-status.md
+14 -15
View File
@@ -4,44 +4,43 @@ Stand: 2026-07-11
## Entscheidung
Ein alter MS-SQL-Datenbankstand steht aktuell nicht zur Verfuegung. Deshalb
koennen `schema-export.sql` und `golden-master-queries.sql` derzeit nicht gegen
eine echte Legacy-Datenbank ausgefuehrt werden.
Ein alter MS-SQL-Datenbankstand steht aktuell nicht zur Verfügung. Deshalb
können `schema-export.sql` und `golden-master-queries.sql` derzeit nicht gegen
eine echte Legacy-Datenbank ausgeführt werden.
Fuer die weitere Umstrukturierung gilt daher:
Für die weitere Umstrukturierung gilt daher:
- Der Legacy-Code ist die primaere Quelle fuer das fachliche Verhalten.
- Der Legacy-Code ist die primäre Quelle für das fachliche Verhalten.
- Die Screenshots unter `docs/m0/screenshots/` sind die visuelle Referenz.
- Die MySQL-Testdatenbank ist die rekonstruierte Entwicklungsbasis.
- Fachliche Golden-Master-Werte werden aus rekonstruierten Testfaellen statt aus
- Fachliche Golden-Master-Werte werden aus rekonstruierten Testfällen statt aus
historischer Produktivdatenbank aufgebaut.
## Konsequenz fuer M1
## Konsequenz für M1
M1 wird nicht als Vergleich gegen echte Alt-Daten gestartet, sondern als
rekonstruierter Golden-Master:
1. Fachliche Regeln aus dem Code ableiten.
2. Kleine, kontrollierte Testdaten erzeugen.
3. Erwartete Salden, Jahreswerte, Striche, Einzahlungen und CSV-Importfaelle
3. Erwartete Salden, Jahreswerte, Striche, Einzahlungen und CSV-Importfälle
manuell beziehungsweise per Testskript definieren.
4. Neue Implementierung gegen diese erwarteten Werte testen.
Wenn spaeter doch noch ein MS-SQL-Dump oder Schemaexport auftaucht, werden die
urspruenglichen M0-SQL-Dateien nachtraeglich genutzt und die Baseline ergaenzt.
Wenn später doch noch ein MS-SQL-Dump oder Schemaexport auftaucht, werden die
ursprünglichen M0-SQL-Dateien nachträglich genutzt und die Baseline ergänzt.
## Aktuelle rekonstruierte Basis
- MySQL-Dev-Schema: `database/mysql-dev-schema.sql`
- Initialisierung: `scripts/init-mysql-dev.php`
- Dev-Start: `scripts/run-dev-server.sh`
- MySQL-Kompatibilitaet: `lib/sqlsrv_mysql_compat.php`
- MySQL-Kompatibilität: `lib/sqlsrv_mysql_compat.php`
## Offene Punkte
- Soll die MySQL-Testdatenbank ab jetzt die verbindliche Entwicklungsdatenbank
fuer M1/M2 sein?
für M1/M2 sein?
- Soll das Ziel weiterhin eine angepasste Legacy-PHP-App sein oder ein sauberer
SaaS-Neuaufbau mit uebernommener Fachlogik?
- Welche Testfaelle muessen fachlich auf jeden Fall abgedeckt werden?
SaaS-Neuaufbau mit übernommener Fachlogik?
- Welche Testfälle müssen fachlich auf jeden Fall abgedeckt werden?
docs/m0/schema-export.sql
+1 -2
View File
@@ -6,7 +6,7 @@ Ziel:
aus der Legacy-Datenbank exportieren.
Hinweise:
- In der Ziel-Datenbank ausfuehren.
- In der Ziel-Datenbank ausführen.
- Ergebnisse als CSV/Excel speichern und nicht mit Produktiv-Secrets ins Repo
legen.
- Falls nur Kaffeelisten-Tabellen exportiert werden sollen, den WHERE-Block bei
@@ -149,4 +149,3 @@ WHERE o.type IN ('P', 'FN', 'IF', 'TF')
OR OBJECT_DEFINITION(o.object_id) LIKE '%CoffeeSurvey%'
)
ORDER BY s.name, o.name;
docs/m0/screenshot-checklist.md
+14 -14
View File
@@ -3,7 +3,7 @@
Stand: 2026-07-11
Diese Checkliste friert die bestehende Optik ein, damit die SaaS-App vertraut
bleibt. Wenn die Legacy-App lokal nicht laeuft, koennen Screenshots aus der
bleibt. Wenn die Legacy-App lokal nicht läuft, können Screenshots aus der
aktuellen Umgebung geliefert werden.
## Allgemeine Vorgaben
@@ -11,24 +11,24 @@ aktuellen Umgebung geliefert werden.
- Je Seite Desktop mit ca. 1440 px Breite aufnehmen.
- Je Kernseite mobile Ansicht mit ca. 390 px Breite aufnehmen.
- Je relevanter Rolle aufnehmen: normales Mitglied und Admin.
- Keine echten personenbezogenen Daten veroeffentlichen.
- Keine echten personenbezogenen Daten veröffentlichen.
- Dateinamen nach Muster `m0-<rolle>-<seite>-<viewport>.png`.
## Kernseiten
| Prioritaet | Seite | Rolle | Status | Zweck |
| Priorität | Seite | Rolle | Status | Zweck |
| --- | --- | --- | --- | --- |
| Hoch | `index.php` | Mitglied | vorhanden: `m0-member-dashboard-desktop.png`, `m0-member-dashboard-mobile.png` | Dashboard, Saldo, Jahreswerte, eigene Striche, PayPal |
| Hoch | `index.php` | Admin | aktuell identisch wie Mitglied | Dashboard mit Admin-Sidebar |
| Hoch | `kaffeeliste.php` | Admin | vorhanden: `m0-admin-kaffeeliste-desktop.png` | Gesamtuebersicht und Aktionsleiste |
| Hoch | `kaffeeliste.php` | Admin | vorhanden: `m0-admin-kaffeeliste-desktop.png` | Gesamtübersicht und Aktionsleiste |
| Hoch | `stricheintragen.php` | Admin | vorhanden: `m0-admin-stricheintragen-desktop.png` | Sammelerfassung Striche |
| Hoch | `einzahlung.php` | Admin | vorhanden: `m0-admin-einzahlung-desktop.png` | Sammelerfassung Einzahlungen |
| Hoch | `mitarbeiterverwalten.php` | Admin | vorhanden: `m0-admin-mitglieder-desktop.png` | Mitgliederliste und Formular |
| Hoch | `letzteneintraege.php` | Admin | vorhanden: `m0-admin-letzteneintraege-desktop.png` | Korrekturansicht mit Loeschaktionen |
| Hoch | `letzteneintraege.php` | Admin | vorhanden: `m0-admin-letzteneintraege-desktop.png` | Korrekturansicht mit Löschaktionen |
| Mittel | `csvupload.php` | Admin | vorhanden: `m0-admin-csv-upload-desktop.png` | CSV-Upload-Formular und Ergebniszustand |
| Mittel | `hinweise.php` | Admin | vorhanden: `m0-admin-hinweise-desktop.png` | Hinweise anlegen und Liste |
| Mittel | `faq.php` | Mitglied | vorhanden: `m0-member-faq-desktop.png` | FAQ-Inhalte und Typografie |
| Mittel | `namenanpassen.php` | Mitglied | offen | Formular fuer Anzeigenamen |
| Mittel | `namenanpassen.php` | Mitglied | offen | Formular für Anzeigenamen |
| Niedrig | `teilnehmerauswertung.php` | Admin | offen | Detailauswertung pro Teilnehmer |
| Niedrig | `mailausgebe.php` | Admin | offen | Mail-/Adressausgabe |
| Niedrig | `umfrage.php` | Mitglied | offen, falls SaaS-relevant | Randmodul, falls SaaS-relevant |
@@ -49,9 +49,9 @@ docs/m0/screenshots/m0-member-dashboard-mobile.png
docs/m0/screenshots/m0-member-faq-desktop.png
```
## Zustaende
## Zustände
Diese UI-Zustaende sollten, wenn moeglich, separat gesichert werden:
Diese UI-Zustände sollten, wenn möglich, separat gesichert werden:
- Positiver Kontostand.
- Negativer Kontostand.
@@ -62,14 +62,14 @@ Diese UI-Zustaende sollten, wenn moeglich, separat gesichert werden:
- CSV-Import mit Erfolg, Dublette und unbekanntem Nutzer.
- Hinweisbanner aktiv.
- Leere Tabellen oder keine Daten.
- Mobile Sidebar geoeffnet und geschlossen.
- Mobile Sidebar geöffnet und geschlossen.
## Designmerkmale, die erhalten bleiben sollen
- Gruener Akzent fuer Links, Buttons und Linien.
- Roboto-Slab-Ueberschriften.
- Open-Sans-Fliesstext.
- Weisse Hauptflaeche.
- Grüner Akzent für Links, Buttons und Linien.
- Roboto-Slab-Überschriften.
- Open-Sans-Fließtext.
- Weiße Hauptfläche.
- Graue Sidebar in der App.
- Tabellen als zentrale Datenansicht.
- Schlichte Formularfelder und Buttons.
@@ -84,5 +84,5 @@ docs/m0/screenshots/
```
Vor dem Commit sollten Screenshots anonymisiert sein. Wenn echte Namen,
E-Mails, PayPal-Daten oder Salden sichtbar sind, besser ausserhalb des Repos
E-Mails, PayPal-Daten oder Salden sichtbar sind, besser außerhalb des Repos
ablegen und nur als Referenz verwenden.
docs/m0/security-baseline.md
+18 -18
View File
@@ -3,17 +3,17 @@
Stand: 2026-07-11
Diese Baseline ist eine statische Erstbewertung. Sie ersetzt kein Penetration
Testing, markiert aber die wichtigsten Risiken fuer die SaaS-Umstrukturierung.
Testing, markiert aber die wichtigsten Risiken für die SaaS-Umstrukturierung.
## Kritische Sofortthemen
| Risiko | Quelle | Auswirkung | Empfehlung |
| --- | --- | --- | --- |
| Hart codierte DB-Zugangsdaten | `jahresauswertung.php` Zeilen 4-8 | Secret-Leak, direkte Produktiv-DB-Gefahr | Zugangsdaten rotieren, Skript deaktivieren oder auf Env-Konfiguration umstellen |
| Schreibende Seiten ohne eigene Rollenpruefung | `stricheintragen.php`, `einzahlung.php`, `mailversenden.php`, `exportKaffeeliste.php` | Direkter URL-Aufruf kann Aktionen erlauben | Jede Seite serverseitig mit `requireRole` absichern |
| CSRF-Schutz nur teilweise vorhanden | viele POST-/Delete-Formulare; M2 hat `hinweise.php`, `mitarbeiterverwalten.php`, `namenanpassen.php`, `index.php`, `stricheintragen.php`, `einzahlung.php`, `letzteneintraege.php`, `csvupload.php` abgesichert | Ungewollte Buchungen, Loeschungen, Imports | CSRF fuer alle verbleibenden schreibenden Aktionen |
| Harte Deletes fuer Buchungen | `letzteneintraege.php` | Audit-Historie und Revisionsfaehigkeit gehen verloren | Storno-/Reversal-Modell statt Delete |
| CSV-Upload nur teilweise gehaertet | `csvupload.php`; M2 speichert temporaer unter `var/uploads`, prueft Dateityp und loescht nach Import | Ohne Importvorschau/Audit bleiben Fehlimporte schwer nachvollziehbar | Importvorschau, Batch-/Audit-Log und detaillierte Zeilenfehler in M6 |
| Schreibende Seiten ohne eigene Rollenprüfung | `stricheintragen.php`, `einzahlung.php`, `mailversenden.php`, `exportKaffeeliste.php` | Direkter URL-Aufruf kann Aktionen erlauben | Jede Seite serverseitig mit `requireRole` absichern |
| CSRF-Schutz nur teilweise vorhanden | viele POST-/Delete-Formulare; M2 hat `hinweise.php`, `mitarbeiterverwalten.php`, `namenanpassen.php`, `index.php`, `stricheintragen.php`, `einzahlung.php`, `letzteneintraege.php`, `csvupload.php` abgesichert | Ungewollte Buchungen, Löschungen, Imports | CSRF für alle verbleibenden schreibenden Aktionen |
| Harte Deletes für Buchungen | `letzteneintraege.php` | Audit-Historie und Revisionsfähigkeit gehen verloren | Storno-/Reversal-Modell statt Delete |
| CSV-Upload nur teilweise gehärtet | `csvupload.php`; M2 speichert temporär unter `var/uploads`, prüft Dateityp und löscht nach Import | Ohne Importvorschau/Audit bleiben Fehlimporte schwer nachvollziehbar | Importvorschau, Batch-/Audit-Log und detaillierte Zeilenfehler in M6 |
| Kein Tenant-Scope | alle fachlichen Queries | Zentrales SaaS-Leak-Risiko | `tenant_id` verpflichtend und Query-Schicht testen |
## Weitere Befunde
@@ -25,10 +25,10 @@ Testing, markiert aber die wichtigsten Risiken fuer die SaaS-Umstrukturierung.
| Datumsformat `Y-d-m H:i:s` | `index.php`, `stricheintragen.php`, `einzahlung.php`, `hinweise.php` | ISO/DB-kompatibel `Y-m-d H:i:s` oder DB-Zeit verwenden |
| Ausgabe von Namen/E-Mails teils unescaped | mehrere Tabellen, z.B. Mitgliederverwaltung | `htmlspecialchars` zentral erzwingen |
| Fehlerausgabe mit `sqlsrv_errors()` an Nutzer | mehrere Dateien | Logging intern, neutrale Fehlermeldung extern |
| CSV-Mitarbeitersuche mit mutmasslich falscher Parameteranzahl | `csvupload.php` `getMitarbeiterID`; in M2 korrigiert | Mit Golden-Master weiter pruefen |
| CSV-Mitarbeitersuche mit mutmaßlich falscher Parameteranzahl | `csvupload.php` `getMitarbeiterID`; in M2 korrigiert | Mit Golden-Master weiter prüfen |
| Basis-Auth-Beispiel mit Platzhalter-Passwort | `umfrageergebnisse.php` Kommentarblock | Entfernen oder echte Auth-Middleware nutzen |
| App-Navigation ist in `footer.php` | Layoutstruktur | Trennung in App-Shell und Public-Shell |
| `headerline.php` enthaelt NUL-Zeichen | `headerline.php` | Datei pruefen/entfernen, wenn ungenutzt |
| `headerline.php` enthält NUL-Zeichen | `headerline.php` | Datei prüfen/entfernen, wenn ungenutzt |
| Massenmail ohne Versandlog | `mailversenden.php`, `jahresauswertung.php` | Job-Modell mit Dry-Run, Audit, Rate-Limit |
## Rollen- und Zugriffsrisiken
@@ -39,29 +39,29 @@ Aktuell gilt:
gesteuert.
- Einige Admin-Zielseiten haben eigene Checks.
- Einige schreibende oder sensible Dateien verlassen sich nicht durchgehend auf
eine eigene Rollenpruefung.
eine eigene Rollenprüfung.
Fuer SaaS gilt:
Für SaaS gilt:
- Menue-Ausblendung ist keine Berechtigungspruefung.
- Jede Route braucht serverseitige Auth- und Rollenpruefung.
- Menü-Ausblendung ist keine Berechtigungsprüfung.
- Jede Route braucht serverseitige Auth- und Rollenprüfung.
- Jede fachliche Route braucht Tenant-Kontext.
- IDs aus Requests muessen zum aktuellen Tenant gehoeren.
- IDs aus Requests müssen zum aktuellen Tenant gehören.
## Empfohlene Reihenfolge fuer Sicherheitsarbeit
## Empfohlene Reihenfolge für Sicherheitsarbeit
1. Secrets rotieren und aus dem Code entfernen.
2. Legacy-Schreibseiten bis zum Umbau hinter explizite Admin-Pruefung setzen.
2. Legacy-Schreibseiten bis zum Umbau hinter explizite Admin-Prüfung setzen.
3. CSRF-Schutz schrittweise auf alle verbleibenden Legacy-Schreibseiten ausrollen.
4. Finanzdaten im Zielmodell nur noch stornieren, nicht loeschen.
4. Finanzdaten im Zielmodell nur noch stornieren, nicht löschen.
5. CSV-Import mit Vorschau, Audit und Zeilenfehlern modellieren.
6. Einheitliche Escape-/View-Helfer einfuehren.
6. Einheitliche Escape-/View-Helfer einführen.
7. Tenant-Isolation mit Tests gegen zwei Tenants absichern.
## Nicht im Repo speichern
- Produktivpasswoerter.
- Produktivpasswörter.
- Echte Nutzerlisten.
- Bank-/PayPal-Exportdaten mit Personenbezug.
- AD-/LDAP-Service-Account-Daten.
- Vollstaendige Produktiv-Dumps.
- Vollständige Produktiv-Dumps.