SnapshotService.CreateAndUploadAsync lädt in zwei Schritten hoch: Schritt 1
holt einen Code vom Server, Schritt 2 verschlüsselt den Sync-Schlüssel mit
diesem Code und lädt erneut hoch. SnapshotStore.Store() vergab bei jedem
Aufruf bedingungslos einen neuen Zufallscode - der dem Nutzer am Ende
angezeigte Code war dadurch nie derselbe, mit dem der Schlüssel tatsächlich
verschlüsselt wurde. Jede Kopplung musste deterministisch an der
Schlüssel-Entschlüsselung scheitern.
SnapshotUploadRequest bekommt ein optionales Code-Feld; Store() aktualisiert
bei vorhandenem, passendem Code denselben Eintrag statt einen neuen mit
neuem Code anzulegen. Betrifft LehrerApp.Api - der Server muss neu deployt
werden.
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>
- PlainEventStore.Allowed: Grade/ExamResult entfernt (beide tragen
StudentId + Notenwert/-kommentar, PlainSyncEvent.Payload läuft aber
als Klartext-JSON über den Server, anders als der AES-256-GCM-
verschlüsselte Desktop-Kanal). Nur noch WorkTask/Lesson erlaubt.
- Regressionstest PlainEventStoreTests ergänzt.
- TODO.md 10.3.3 abgehakt, inkl. deutlichem Warnhinweis: die geplante
Mitarbeitsnoten-Erfassung per Companion-App ist damit bewusst
blockiert, bis 10.3.1 (Schlüsselaustausch) + eine echte Payload-
Verschlüsselung für PlainSyncEvent existieren.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Anhaenge laufen bewusst NICHT ueber den JSON-Ereigniskanal (wuerde ihn
fuer Fotos/Scans stark aufblaehen), sondern ueber einen eigenen
verschluesselten Binaerkanal - analog zum bereits bestehenden Muster
in SnapshotService.
- Neue Endpunkte POST/GET /api/sync/attachments/{storageId} in
LehrerApp.Api (AttachmentStore, dateibasiert je Nutzer)
- EventQueue: neue, vom JSON-Ereignis getrennte Warteliste fuer
ausstehende Uploads (SyncEventPublisher traegt Anhaenge einer
gespeicherten Documentation dort ein)
- AttachmentSyncer laedt ausstehende Anhaenge hoch (in
SyncEngine.SyncNowAsync nach dem Event-Push)
- EventApplier laedt fehlende Anhaenge nach dem Anwenden eines
Documentation-Ereignisses nach - ueber die rohe Collection statt
IAttachmentStorage.Upload, da dieses immer eine neue Id vergaebe und
hier die Original-StorageId erhalten bleiben muss
Round-Trip-Tests belegen byteidentische Uebertragung.
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>
adminandClaude Sonnet 5