kleiderboerse/Plan.md

Umsetzungsplan – Kinderkleider-Börse

Grundlage: projekt.md. Dieser Plan ergänzt sie um die Entscheidungen, die dort offen waren, und um die Punkte, die durch den Internet-Zugang dazukommen.

Getroffene Entscheidungen

Frage	Entscheidung
Frontend	Variante A – Jinja2 + HTMX + Tailwind, ein einziger Dienst, kein Node.js
Erfassen/Bearbeiten/Löschen	Hinter einem Passwort
Reservieren	Ohne Anmeldung
Erreichbarkeit	Aus dem Internet, per Reverse-Proxy mit HTTPS

Die letzten beiden zusammen sind der eigentliche Knackpunkt dieses Projekts: ein Endpunkt, den jeder im Internet ohne Anmeldung auslösen kann, der den Zustand ändert. Alles unter „Absicherung" ergibt sich daraus.

---

Architektur

Ein Container, ein Prozess (uvicorn), eine SQLite-Datei. FastAPI liefert sowohl die REST-API (/api/v1/...) als auch die gerenderten Seiten aus – dieselbe Anwendung, dieselben CRUD-Funktionen. HTMX ersetzt beim Filtern und Reservieren nur Teilbereiche der Seite, statt eine SPA zu bauen.

Tailwind ohne Node.js: nicht per CDN (im Betrieb nicht vorgesehen und wäre eine Fremdverbindung), sondern über die Standalone-CLI – eine einzelne Binärdatei, die im Docker-Build einmalig ein fertiges style.css erzeugt. Im Image landet nur das fertige CSS.

Persistenz: ein Volume für die Datenbank, ein zweites für die Bilder. Beide ausserhalb des ausgelieferten Codes.

Projektstruktur

Die Struktur in projekt.md ist an einer Stelle verrutscht (die Module stehen auf derselben Ebene wie app/, static/ und templates/ hängen an einer Ebene, die es nicht gibt). Vorschlag:

kleiderboerse/
├── app/
│   ├── __init__.py
│   ├── main.py            # FastAPI-App, Startup, Router einhängen
│   ├── config.py          # Einstellungen aus Umgebungsvariablen
│   ├── database.py        # Engine & Session
│   ├── models.py          # SQLAlchemy-Modelle
│   ├── schemas.py         # Pydantic-Schemas
│   ├── crud.py            # Datenbankzugriffe
│   ├── security.py        # Passwort, Sitzung, CSRF, Rate-Limit
│   ├── images.py          # Upload-Prüfung, WebP-Konvertierung
│   ├── routers/
│   │   ├── items.py       # /api/v1/items
│   │   ├── categories.py  # /api/v1/categories, /sizes
│   │   └── pages.py       # HTML-Seiten (Galerie, Detail, Erfassen)
│   ├── static/            # erzeugtes CSS, Icons  (Bilder NICHT hier)
│   └── templates/
├── alembic/               # Migrationen
├── data/                  # Volume: kleiderboerse.sqlite
├── uploads/               # Volume: hochgeladene Bilder
├── tests/
├── Dockerfile
├── docker-compose.yml
├── requirements.txt
└── README.md

Hochgeladene Bilder liegen nicht unter static/, sondern in einem eigenen Verzeichnis, das über eine eigene Route ausgeliefert wird. Sonst wäre jede hochgeladene Datei unter ihrem Namen direkt abrufbar – und ein als Bild getarntes Skript ebenfalls.

---

Datenmodell – Abweichungen von projekt.md

Das Schema wird grundsätzlich übernommen. Vier Ergänzungen:

1. Feste Wertelisten statt freier VARCHAR. gender, season, condition und status bekommen ein Python-Enum plus CHECK-Bedingung in der Datenbank. Ohne das schleicht sich über die API früher oder später "Gril" oder "reserviert" ein, und die Filter greifen dann still nicht mehr.

2. reservation_token (neu) in items. Zufälliger Wert, der beim Reservieren erzeugt wird. Nur wer ihn hat, kann die eigene Reservierung wieder aufheben. Begründung unten unter „Offene Punkte".

3. sizes als eigene Tabelle. projekt.md sieht GET /api/v1/sizes vor, aber keine Tabelle dazu. Grössen aus den vorhandenen Einträgen zu destillieren (SELECT DISTINCT size) klingt bequem, sortiert aber falsch (98/104 vor 24) und liefert Tippfehler gleich mit als Filteroption. Darum eine gepflegte Liste mit sort_order.

4. updated_at wird in der Anwendung gesetzt, nicht per DB-Trigger – bleibt so unabhängig von SQLite-Eigenheiten.

Ausserdem: beim Löschen eines Eintrags müssen die Bilddateien mitgelöscht werden, sonst wächst das Upload-Verzeichnis unbegrenzt mit verwaisten Dateien. ON DELETE CASCADE räumt nur die Datenbankzeilen weg, nicht die Dateien.

---

Absicherung

Die App ist aus dem Internet erreichbar, also gelten hier andere Massstäbe als bei einem Heimnetz-Dienst. Punkte 1 und 2 sind die wichtigsten.

1. Bild-Upload – die grösste Angriffsfläche

• Dateiname nie aus dem Upload übernehmen, sondern selbst erzeugen (UUID + .webp). Damit ist Pfad-Manipulation ausgeschlossen.
• Vor dem Öffnen: Grösse begrenzen (z.B. 10 MB) und Inhaltstyp prüfen.
• Image.MAX_IMAGE_PIXELS setzen – sonst kann ein wenige Kilobyte grosses PNG beim Entpacken den Arbeitsspeicher füllen („Dekompressionsbombe").
• Nach dem Konvertieren nach WebP wird nur das Ergebnis gespeichert, nie das Original. Das entfernt eingebettete Fremdinhalte und die EXIF-Daten – letztere enthalten bei Handyfotos oft die GPS-Koordinaten der Wohnung.
• Ausliefern mit festem Content-Type: image/webp und X-Content-Type-Options: nosniff.

2. Reservieren ohne Anmeldung

Ein offener, zustandsändernder Endpunkt im Internet. Ohne Bremse kann ein Skript in Sekunden alles reservieren oder reserved_by als Werbefläche missbrauchen.

• Rate-Limit pro IP (slowapi), z.B. 5 Reservierungen pro Stunde.
• reserved_by begrenzen (Länge, keine URLs) und beim Anzeigen maskieren. Jinja2 maskiert von sich aus – entscheidend ist, |safe dort nirgends zu verwenden.
• Reservierungen sind jederzeit vom Betreiber aufhebbar (Admin-Ansicht), damit eine Missbrauchswelle in einem Rutsch aufgeräumt werden kann.

3. Anmeldung fürs Erfassen

• Passwort als bcrypt-Hash aus einer Umgebungsvariablen. Kein Standardpasswort mitliefern: ohne gesetzten Wert ist der Bereich gesperrt, nicht offen.
• Hash einmal beim Start berechnen, nicht pro Anfrage.
• Sitzungs-Cookie HttpOnly, SameSite=Lax, Secure.
• Secure muss X-Forwarded-Proto auswerten, nicht nur die direkte Verbindung – hinter einem TLS-Reverse-Proxy sieht die App sonst „HTTP" und lässt das Cookie unverschlüsselt mitgehen.
• Rate-Limit auch auf die Anmeldung, plus Sitzungs-Timeout.
• CSRF-Token für alle ändernden Formulare.

4. Allgemein

• Content-Security-Policy mit script-src 'self' (HTMX wird lokal ausgeliefert, nicht per CDN), dazu nosniff und frame-ancestors 'none'.
• HTTPS erzwingen; uvicorn mit --proxy-headers und gesetzten forwarded-allow-ips.
• Fehlermeldungen ohne interne Details; Stacktraces nur ins Log.
• Pagination auf GET /api/v1/items – ohne Begrenzung liefert der Endpunkt irgendwann alle Einträge samt Bildpfaden in einer Antwort.

5. Personendaten

reserved_by ist ein Personenname auf einer öffentlich erreichbaren Seite. Vorschlag: auf der Galerie nur „reserviert" anzeigen, den Namen ausschliesslich in der Admin-Ansicht. Zusätzlich beim Erledigen (mark-given) den Namen löschen. Das ist datensparsam und macht die Seite gleichzeitig unattraktiver für Spam.

---

Meilensteine

Die Phasen aus projekt.md, ergänzt um Tests und die Absicherung.

Phase 1 – Fundament

• Projektgerüst, requirements.txt, Einstellungen aus Umgebungsvariablen
• SQLAlchemy-Modelle, Alembic-Erstmigration, Kategorien und Grössen vorbefüllen
• CRUD-Schicht mit Tests
• GET/POST/PATCH/DELETE /api/v1/items, GET /api/v1/categories, /sizes
• Prüfpunkt: über Swagger UI ein Kleidungsstück anlegen, filtern, ändern, löschen

Phase 2 – Bilder

• Upload per multipart/form-data, mehrere Bilder pro Eintrag
• Prüfung und WebP-Konvertierung (max. 1200 px Breite) nach Abschnitt 1 oben
• Ausliefer-Route, is_primary-Logik, Aufräumen beim Löschen
• Prüfpunkt: bewusst fehlerhafte Uploads (zu gross, falscher Typ, riesige Pixelmasse, .php als .jpg getarnt) werden alle abgewiesen

Phase 3 – Absicherung

• Anmeldung, Sitzung, CSRF, Rate-Limits, Sicherheits-Header
• Prüfpunkt: ohne Anmeldung ist kein Schreibzugriff möglich; ohne gesetztes Passwort ist der Erfassungsbereich gesperrt

Phase 4 – Oberfläche

• Mobile-First-Layout, Galerie mit Filterleiste (HTMX)
• Detailseite, Erfassungsformular mit Kamera-Aufnahme (<input type="file" accept="image/*" capture="environment">)
• Reservierungs-Ablauf inklusive Selbst-Freigabe
• Prüfpunkt: der ganze Weg auf einem echten Smartphone

Phase 5 – Betrieb

• Dockerfile (Tailwind-Build inbegriffen), docker-compose.yml, Volumes
• Healthcheck, Backup-Hinweise für Datenbank und Bilder
• Gitea Actions: Image bauen und in die Registry stellen (siehe unten)
• Zwei Compose-Dateien wie bei der Kantone-App: eine zum Selberbauen aus dem Quellcode, eine zum blossen Starten des fertigen Images
• README für Einrichtung und Reverse-Proxy

Bauen über Gitea Actions

Gleiches Vorgehen wie bei der Kantone-App (.gitea/workflows/docker-image.yml dort als Vorlage):

• Auslöser: nur ein Versions-Tag (v*) oder ein manueller Start (workflow_dispatch) – nicht jeder Push auf main. Dadurch bleibt das Zusammenführen von Branches folgenlos, und ein Release ist ein bewusster Schritt.
• Registry: gitea.boing86.myds.me, Image docker/kleiderboerse.
• Version: aus dem Tag (v1.2.3 → 1.2.3), bei manuellen Läufen ein Zeitstempel. Tag und Commit werden als Build-Argumente durchgereicht und in der Fusszeile angezeigt – so ist sofort erkennbar, welcher Stand läuft.
• Test vor der Veröffentlichung: Container starten und prüfen, bevor irgendetwas in die Registry geht. Bei der Kantone-App wird die API auf 26 Kantone geprüft; hier wären die Entsprechungen: Startseite antwortet mit 200, /api/v1/categories liefert die vorbefüllten Kategorien, und ein Testupload wird tatsächlich als WebP abgelegt. Schlägt das fehl, wird nichts veröffentlicht.
• latest nur für echte Versions-Tags, nicht für manuelle Läufe.
• Anmeldung über --password-stdin (das Token taucht so weder in der Prozessliste noch im Protokoll auf), docker logout mit if: always(). Zugangsdaten als Repo-Secrets (REGISTRY_TOKEN, REGISTRY_USER), nicht im Workflow.
• Rechte im Job auf contents: read und packages: write begrenzen.
• Werte aus ${{ ... }} nie direkt in die Shell schreiben, sondern über env: durchreichen. Ausdrücke werden vor der Shell ersetzt, und Tag-Namen dürfen Zeichen wie " oder $ enthalten – sonst lässt sich über einen präparierten Tag Code auf dem Runner ausführen, in einem Job, der ein Registry-Token hält. (Genau das wurde in der Kantone-App nachträglich korrigiert.)

---

Offene Punkte

1. Wer darf eine Reservierung wieder aufheben? projekt.md sieht POST /items/{id}/release vor, sagt aber nicht, wer ihn aufrufen darf. Ist er offen, kann jeder die Reservierung eines anderen löschen. Vorschlag: beim Reservieren wird ein Token vergeben und als Link angezeigt („Reservierung aufheben") – wer ihn hat, kann die eigene zurücknehmen; der Betreiber kann es ohnehin. Bitte bestätigen, dann kommt reservation_token ins Modell.

2. Soll die Galerie überhaupt öffentlich sein? Auch ohne Schreibzugriff zeigt sie Kinderkleidung, Namen und indirekt den Wohnort. Ein einfacher Zugangscode für die ganze Seite (einmal eingeben, bleibt im Cookie) würde Suchmaschinen und Zufallsbesucher aussperren, ohne dass jemand ein Konto braucht. Empfehlung: ja, zusätzlich zu noindex. Deine Entscheidung.

3. Benachrichtigung bei Reservierung? Nicht in projekt.md. Ohne sie musst du selbst nachschauen. Ein einfacher Weg wäre eine Nachricht per E-Mail oder Telegram. Kann auch später kommen – dann aber besser gleich als eigener Meilenstein statt nachträglich eingeschoben.

4. Mehrere Kinder / Grössenverläufe? Aktuell ist alles ein flacher Bestand. Falls du später nach „von wem" oder „Jahrgang" filtern willst, wäre jetzt der günstige Zeitpunkt für ein zusätzliches Feld.