./data war ein Bind-Mount relativ zum Git-Checkout - bei Dokploy wird
das Repo pro Deploy frisch geklont, ein per CLI angelegter Nutzer war
nach einem reinen Routing-Redeploy spurlos verschwunden. Betraf nicht
nur Nutzer, sondern denselben Api:DataPath für Ereignis-Log/Snapshots/
Anhänge - also jeden Server-Datenbestand bei jedem Redeploy.
- docker-compose.yml: Named Volume "api-data" statt Bind-Mount, lebt
unabhängig vom Checkout im Docker-Daemon.
- backup.sh: auf volume-basiertes Backup umgeschrieben (Alpine-
Hilfscontainer statt direktem Host-Pfad).
- docker/README.md, TODO.md 10.2.4: Vorfall dokumentiert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
create-user lehnt einen bereits existierenden Nutzernamen ab und
UserStore hatte keinen Weg, ein Passwort nachträglich zu ändern -
einzige Alternative wäre manuelles Editieren der LiteDB-Binärdatei
gewesen. Neuer Befehl set-password <benutzername> [--password <pw>]
nach demselben Muster wie create-user (Cli.ParsePassword extrahiert,
von beiden Befehlen geteilt). docker/README.md ergänzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kurzanleitung ergänzt, wie die API über Dokploys Git-basiertes
Compose-Deployment ausgerollt wird (Repo-URL, Compose-Path,
JWT_SECRET als Env-Var, Domain/Port, Auto-Deploy-Webhook,
Nutzeranlage) – ersetzt den zunächst erwogenen manuellen
ZIP-Upload-Workaround.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Rate Limiting ueber ASP.NET Cores eingebautes
Microsoft.AspNetCore.RateLimiting (keine neue Paketabhaengigkeit):
/api/auth/login auf 5 Versuche/Minute begrenzt (Brute-Force-Schutz),
alle Endpunkte zusaetzlich global auf 120 Anfragen/Minute je IP
- Kestrel MaxRequestBodySize auf 15 MB gedeckelt (Anhaenge sind
clientseitig ohnehin auf 10 MB begrenzt)
- Neu docker/backup.sh: Tar-Archiv von ./data (Ereignis-Logs,
Snapshots, Anhaenge, Nutzer), raeumt Archive aelter als 30 Tage auf,
laeuft direkt auf dem Host
- docker/README.md um Backup- und Rate-Limit-Dokumentation ergaenzt
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
/api/auth/login und /api/auth/register akzeptierten zuvor jeden
beliebigen Nutzernamen/Passwort und stellten ein gueltiges 30-Tage-JWT
aus - konkrete, ausnutzbare Luecke bei echtem Deployment.
- PasswordHasher (PBKDF2, Salt pro Nutzer) + UserStore (LiteDB) statt
des ungeprueften Stubs
- /api/auth/register ersatzlos entfernt (kein offener
Registrierungs-Endpunkt fuer ein Einzel-/Familien-Deployment)
- Neue Nutzer per CLI (dotnet LehrerApp.Api.dll create-user <name>),
dokumentiert in docker/README.md
- Neues Testprojekt LehrerApp.Api.Tests (bisher als einziges Projekt
ohne Tests)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
admin
