Auto-commit: 2026-05-22 14:42

2026-05-22 14:42:55 +00:00
parent d8db022c65
commit c3e17a04e0
28 changed files with 1197 additions and 1 deletions
--- a/memory/gitea-specs/issue-41.md
+++ b/memory/gitea-specs/issue-41.md
@@ -0,0 +1,47 @@
+# Issue #41 – CSP Header implementieren
+
+## Komplexität: S (Small)
+- Header-Zeile in index.php oder .htaccess hinzufügen
+- Geschätzter Aufwand: < 30 Min
+
+## Analyse
+Statische Landingpage, keine dynamischen Scripte von Drittanbietern. CSP kann sehr restriktiv sein.
+
+### Externe Ressourcen
+- Google Maps iframe: `frame-src https://www.google.com/maps/`
+- Lokale Fonts: `/fonts/` → `'self'`
+- Lokale CSS: `/css/` → `'self'`
+- Lokale JS: `/js/haus-schleusingen.js` → `'self'`
+- Bilder: `'self' data:` (fuer inline-Bilder)
+- `unsafe-inline` fuer Styles vermeiden → pruefen ob noetig
+
+### Architektur-Entscheidung
+CSP Header in `public/.htaccess` setzen (nicht in PHP), da:
+- Zentraler Ort, einfach wartbar
+- Kein PHP-Code noetig
+- Apache-spezifisch, aber das ist die Produktionsumgebung
+
+### CSP-Richtlinie
+```
+Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; frame-src https://www.google.com/ https://www.google.de/; connect-src 'self'
+```
+
+Hinweis: `unsafe-inline` fuer styles vorerst beibehalten, da inline-styles in Views verwendet werden (z.B. hero-bg `style="background-image:..."`). Spaeter durch Nonce/Hash ersetzen.
+
+### Akzeptanzkriterien
+- [ ] CSP-Header wird in jeder Response gesendet
+- [ ] Alle Ressourcen (CSS, JS, Fonts, Bilder) laden korrekt
+- [ ] Google Maps iframe funktioniert
+- [ ] Keine CSP-Verletzungen im Browser-Console
+
+### Abhängigkeiten
+Keine. Unabhaengig von anderen Issues.
+
+### Edge Cases
+- `data:` URIs fuer Bilder -> `img-src 'self' data:`
+- Google Maps iframe kann auch `www.google.de` nutzen
+- `unsafe-inline` styles: View-Templates nutzen `style="..."` Attribute
+
+### Sicherheitsrisiken
+- `unsafe-inline` fuer styles: Minimales Risiko, aber acceptable fuer Landingpage
+- Keine `unsafe-eval` oder `unsafe-inline` fuer scripts
--- a/memory/gitea-specs/issue-42.md
+++ b/memory/gitea-specs/issue-42.md
@@ -0,0 +1,59 @@
+# Issue #42 – CSRF-Schutz für Kontaktformular
+
+## Komplexität: S (Small)
+- Token-Generierung, Hidden-Field, Validierung
+- Geschätzter Aufwand: < 30 Min
+
+## Analyse
+Kontaktformular in HomeController. Session wird bereits gestartet. CSRF-Token muss vor Formular-Render generiert und bei POST validiert werden.
+
+### Aktueller Formular-Flow
+1. `session_start()` in HomeController::index()
+2. POST-Verarbeitung mit Validierung
+3. Redirect nach Verarbeitung (PRG-Pattern)
+4. Session speichert Formular-Status
+
+### Architektur-Entscheidung
+CSRF-Token direkt in HomeController implementieren:
+1. Token beim GET-Request generieren und in Session speichern
+2. Token als Hidden-Field im Formular ausgeben
+3. Bei POST: Token validieren bevor Verarbeitung
+
+### Implementierung
+```php
+// GET: Token generieren
+if (empty($_SESSION['csrf_token'])) {
+    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
+}
+
+// POST: Token validieren
+if ($_SERVER['REQUEST_METHOD'] === 'POST') {
+    $csrfToken = $_POST['csrf_token'] ?? '';
+    if (!hash_equals($_SESSION['csrf_token'] ?? '', $csrfToken)) {
+        // CSRF-Fehler
+        header('Location: /#form-result');
+        exit;
+    }
+    // ... bestehende Validierung
+}
+```
+
+Im View: `<input type="hidden" name="csrf_token" value="<?= htmlspecialchars($_SESSION['csrf_token'] ?? '') ?>">`
+
+### Akzeptanzkriterien
+- [ ] CSRF-Token wird bei jedem GET generiert
+- [ ] Token ist als Hidden-Field im Formular vorhanden
+- [ ] POST ohne gueltiges Token wird abgelehnt
+- [ ] Formular funktioniert weiterhin korrekt mit Token
+
+### Abhängigkeiten
+Keine. Unabhaengig von anderen Issues.
+
+### Edge Cases
+- Token muss nach erfolgreicher Validierung nicht regeneriert werden (kein Login-Kontext)
+- Mehrere Tabs: Gleicher Token pro Session ist ok
+- Honeypot-Feld: Muss vor CSRF-Check kommen (sonst CSRF-Fehler beim Bot-Trap)
+
+### Sicherheitsrisiken
+- `hash_equals()` statt `===` verwenden (timing-safe Vergleich)
+- Token-Laenge: 64 Hex-Zeichen (32 Bytes) ausreichend
--- a/memory/gitea-specs/issue-43.md
+++ b/memory/gitea-specs/issue-43.md
@@ -0,0 +1,36 @@
+# Issue #43 – Offene Redirects via REQUEST_URI fixen
+
+## Komplexität: S (Small)
+- `$_SERVER['REQUEST_URI']` durch festen Pfad ersetzen
+- Geschätzter Aufwand: < 10 Min
+
+## Analyse
+HomeController nutzt `$_SERVER['REQUEST_URI']` an 3 Stellen fuer Redirects:
+1. Nach Honeypot-Fang: `header('Location: ' . $_SERVER['REQUEST_URI'] . '#form-result');`
+2. Nach erfolgreichem Mail-Versand: `header('Location: ' . $_SERVER['REQUEST_URI'] . '#form-result');`
+3. Bei Fehlern: `header('Location: ' . $_SERVER['REQUEST_URI'] . '#form-result');`
+
+Da alle Redirects zur Startseite + Anker fuehren, kann `REQUEST_URI` durch festen Pfad ersetzt werden.
+
+### Architektur-Entscheidung
+Alle 3 Vorkommen von `$_SERVER['REQUEST_URI']` ersetzen durch:
+```php
+header('Location: /#form-result');
+```
+
+Das ist sicher, da das Kontaktformular nur auf der Startseite existiert.
+
+### Akzeptanzkriterien
+- [ ] Kein `$_SERVER['REQUEST_URI']` mehr in Redirects
+- [ ] Redirect fuehrt korrekt zur Startseite mit #form-result Anker
+- [ ] PRG-Pattern funktioniert weiterhin (Erfolg/Fehler-Nachrichten)
+
+### Abhängigkeiten
+Keine. Unabhaengig von anderen Issues.
+
+### Edge Cases
+- Falls das Formular spaeter auf anderen Seiten eingebaut wird:.Relative Pfade anpassen. Aktuell nur Startseite.
+- Query-Parameter gehen verloren – aber das ist ok, da PRG ueber Session arbeitet.
+
+### Sicherheitsrisiken
+- Keine. Fester Pfad ist per Definition sicher gegen Open Redirects.
--- a/memory/gitea-specs/issue-54-review.md
+++ b/memory/gitea-specs/issue-54-review.md
@@ -0,0 +1,126 @@
+# Code Review: PR #55 – Fix #54: Pre-Commit Hook als Gate für jeden Commit
+
+**Reviewer:** Claw (AI Code Reviewer)
+**Datum:** 2026-05-22
+**Branch:** feature/issue-54-precommit-lint-gate → main
+**Betreffene Issues:** #53 (PR-Gate / Branch Protection), #54 (Pre-Commit Hook als Gate)
+
+---
+
+## Zusammenfassung
+
+PR #55 integriert Lint-Checks (PHP, CSS, HTML) als Gate in den CI-Deploy-Workflow und ergänzt PHP-Lint im Pre-Commit Hook. Zudem werden Helper-Scripts für AI-Agent-Commits bereitgestellt.
+
+---
+
+## Geänderte Dateien
+
+| Datei | Änderung |
+|-------|----------|
+| `.gitea/workflows/deploy-test.yml` | 3 neue Lint-Jobs (PHP, CSS, HTML) + `needs`-Abhängigkeit für Deploy |
+| `AGENTS.md` | Pre-Commit-Hook-Dokumentation, OS-Korrektur Windows→Linux |
+| `package.json` | `lint:php`-Script + `lint-staged` Eintrag für `.php`-Dateien |
+| `scripts/lint-php.sh` | **Neu** – Pre-Commit PHP Syntax-Check |
+| `scripts/safe-commit.sh` | **Neu** – Commit-Wrapper mit garantiertem Lint-Run |
+
+---
+
+## Code-Quality-Checkliste
+
+| Kriterium | Bewertung | Anmerkung |
+|-----------|-----------|-----------|
+| Funktionslänge | ✅ Gut | Alle Funktionen/Scripts sind kurz und fokussiert |
+| Dateilänge | ✅ Gut | Keine überlangen Dateien |
+| Error-Handling | ✅ Gut | `set -euo pipefail` in Scripts, Exit-Codes korrekt |
+| Input-Validation | ✅ Gut | `safe-commit.sh` prüft ob Argument vorhanden |
+| Secrets | ✅ Keine | Keine Secrets im Code |
+| Namensgebung | ✅ Klar | `lint-php.sh`, `safe-commit.sh` – selbsterklärend |
+| DRY | ⚠️ Minor | `lint:php` in package.json dupliziert Logik aus `lint-php.sh` (anderer Ansatz, aber gleicher Zweck) |
+| Konsistenz | ✅ Gut | Shell-Scripts folgen bash-idiomatischem Stil |
+
+---
+
+## Sicherheitsprüfung
+
+- ✅ Keine Secrets, Tokens oder Credentials im Code
+- ✅ Keine unsichere `eval`/`exec`-Konstrukte
+- ✅ `set -euo pipefail` in allen Scripts
+- ✅ Keine Shell-Injection-Vektoren (File-Argumente korrekt gequotet)
+
+---
+
+## Architekturkonformität
+
+- ✅ Lint-Jobs korrekt als separate Jobs im CI-Workflow
+- ✅ Deploy-Job hat `needs: [lint-php, lint-css, lint-html]` → Deploy nur bei grünen Lints
+- ✅ Pre-Commit Hook (`.husky/pre-commit` → `npx lint-staged`) bleibt intakt
+- ✅ `safe-commit.sh` als ergänzender Wrapper für AI-Agents
+
+---
+
+## Potenzielle Probleme
+
+### 1. Lint-Check läuft doppelt bei `safe-commit.sh`
+`safe-commit.sh` führt `npx lint-staged` manuell aus und danach `git commit` (was wieder den Pre-Commit Hook triggert, der `lint-staged` nochmal ausführt). Das ist bewusst als Safety-Net, führt aber bei jedem Commit zu doppeltem Lint-Lauf.
+
+**Bewertung:** Akzeptabel – ist explizit so designed, Performance-Impact minimal bei dieser Projektgröße.
+
+### 2. `lint:php` in package.json vs. `scripts/lint-php.sh`
+Das `lint:php`-Script in `package.json` ist ein komplexer Einzeiler, der die gleiche Aufgabe wie `scripts/lint-php.sh` hat, aber mit anderer Fehlerbehandlung (leitet alles nach `/dev/null` um, gibt weniger hilfreiche Fehlermeldungen). lint-staged nutzt das Shell-Script, was besser ist.
+
+**Bewertung:** Nicht kritisch, aber könnte in Zukunft vereinheitlicht werden.
+
+### 3. CI-Jobs installieren Pakete bei jedem Run
+Kein Caching von `apt-get`/`npm install`. Bei dieser Projektgröße verschwindend gering.
+
+**Bewertung:** Akzeptabel.
+
+### 4. `cp index.html` entfernt
+Die Zeile `cp /deploy/haus-schleusingen.html /deploy/index.html` wurde entfernt. Falls `index.html` nicht anderweitig bereitgestellt wird, könnte das zu einem 404 führen.
+
+**Bewertung:** ⚠️ **Prüfen!** Wird `index.html` jetzt durch andere Mechanismen bereitgestellt (z.B. nginx rewrite)? Falls nicht, ist das ein Breaking Change.
+
+---
+
+## Akzeptanzkriterien-Prüfung
+
+### Issue #53 – PR-Gate / Branch Protection
+
+| Kriterium | Status | Anmerkung |
+|-----------|--------|-----------|
+| Branch-Schutz für `main` aktiviert: erfordert erfolgreiche Status-Checks vor Merge | ❌ **Nicht im Code** | Branch Protection ist eine Gitea-Repo-Einstellung, nicht im PR-Code konfigurierbar. Muss manuell im Repo-Admin gesetzt werden. |
+| Status-Checks `lint-php`, `lint-css`, `lint-html` als erforderlich konfiguriert | ❌ **Nicht im Code** | Gleicher Grund – Gitea-Setting. Die Jobs existieren aber korrekt im Workflow. |
+| PR zeigt Test-Ergebnisse als Checks an | ✅ Erfüllt | Lint-Jobs laufen bei Push auf feature/**, werden im PR sichtbar |
+| Deploy auf Testumgebung erfolgt nur bei grünen Tests | ✅ Erfüllt | `needs: [lint-php, lint-css, lint-html]` im deploy-test.yml |
+| Dokumentation der Einstellungen im Repo | ⚠️ Teilweise | AGENTS.md aktualisiert, aber keine explizite Doku der Branch Protection Settings |
+
+### Issue #54 – Pre-Commit Hook als Gate
+
+| Kriterium | Status | Anmerkung |
+|-----------|--------|-----------|
+| `lint-staged` enthält PHP Syntax-Check | ✅ Erfüllt | `"*.{php}": ["scripts/lint-php.sh"]` in package.json |
+| Pre-Commit Hook prüft: PHP, HTML, CSS, JS, Prettier | ✅ Erfüllt | lint-staged + .husky/pre-commit covers all |
+| Hook läuft auch bei AI-Agent / non-interactive | ✅ Erfüllt | `safe-commit.sh` + `core.hooksPath`-Setting |
+| Klare Fehlermeldung bei Linter-Fehler | ✅ Erfüllt | `lint-php.sh` und `safe-commit.sh` haben klare Messages |
+| README dokumentiert Hook-Aktivierung | ❌ **Nicht erfüllt** | AGENTS.md aktualisiert, aber README enthält keine Doku. Kriterium fordert explizit README. |
+| AI-Agent-Anweisung in AGENTS.md | ✅ Erfüllt | Ausführliche Dokumentation vorhanden |
+
+---
+
+## Fazit
+
+### Gesamtbewertung: **CHANGES_REQUESTED** (minor)
+
+**Was gut ist:**
+- Saubere Integration der Lint-Gates in den CI-Workflow
+- Korrekte `needs`-Abhängigkeit verhindert Deploy bei fehlgeschlagenen Lints
+- Gute Scripts mit fehlerresistentem Error-Handling
+- Durchdachte AI-Agent-Unterstützung (`safe-commit.sh`)
+
+**Was noch fehlt:**
+
+1. **🔴 `index.html`-Entfernung prüfen:** Das Entfernen von `cp haus-schleusingen.html index.html` im Deploy könnte die Seite kaputt machen. Bitte prüfen ob `index.html` anderweitig bereitgestellt wird.
+
+2. **🟡 Issue #54 Kriterium "README dokumentiert":** README.md enthält keine Anleitung zur Hook-Aktivierung. Entweder README ergänzen oder Akzeptanzkriterium anpassen.
+
+3. **🟡 Issue #53 Branch Protection:** Kann nicht im Code gelöst werden – muss manuell in Gitea konfiguriert werden. Sollte nach PR-Merge manuell durchgeführt werden. Die CI-seitigen Voraussetzungen (Lint-Jobs) sind aber korrekt implementiert.
--- a/memory/gitea-specs/issues-41-42-43-review.md
+++ b/memory/gitea-specs/issues-41-42-43-review.md
@@ -0,0 +1,40 @@
+# Code Review – Issues #41, #42, #43
+
+**Reviewer:** Claw (Self-Review)
+**Datum:** 2026-05-03
+
+## Issue #41 – CSP Header
+**Status: ✅ APPROVED**
+- CSP-Richtlinie korrekt für statische Landingpage
+- Zusätzliche Security-Header (X-Content-Type-Options, X-Frame-Options, Referrer-Policy)
+- `<IfModule>` schützt vor Fehlern
+
+## Issue #42 – CSRF-Schutz
+**Status: ✅ APPROVED**
+- `random_bytes(32)` für Token-Generierung
+- `hash_equals()` für timing-safe Vergleich
+- Validierung VOR Honeypot-Check
+- `htmlspecialchars()` im View für Token-Output
+
+## Issue #43 – Open Redirect Fix
+**Status: ✅ APPROVED**
+- Alle 3 REQUEST_URI-Vorkommen ersetzt durch festen Pfad `/`
+- Keine Verhaltensänderung für Benutzer
+
+## Code-Quality-Checkliste
+| Check | Ergebnis |
+|---|---|
+| Funktionslänge | ✅ |
+| Dateilänge | ✅ |
+| Verschachtelung | ✅ |
+| Magic Numbers | ✅ |
+| Console.log | ✅ |
+| Dead Code | ✅ |
+| Ternary-Chains | ✅ |
+| Dependencies | ✅ |
+| Error-Handling | ✅ |
+| Input-Validation | ✅ |
+| Secrets | ✅ |
+| Typsicherheit | ✅ |
+
+**Gesamt: APPROVED** – keine Must-Fix, keine Should-Fix.