Files

T

ScarriffleandClaude Opus 5 7fc8763d57 feat: 2FA, Passwortrichtlinie und wiederherstellbares JSON-Backup

Zwei-Faktor per TOTP mit zehn Einmal-Wiederherstellungscodes. Der
Zwischenzustand "Passwort stimmt, Code fehlt" haengt an der vorhandenen
Sitzungstabelle (pending_2fa, zehn Minuten Laufzeit) und gilt nirgends als
angemeldet; nach dem Code wird das Cookie getauscht statt weiterverwendet.
Der Wiederverwendungsschutz merkt sich das tatsaechlich getroffene
Zeitfenster, nicht die aktuelle Uhrzeit - sonst liesse sich ein Code aus dem
naechsten Fenster gleich darauf nochmal einloesen.

Passwortrichtlinie (Laenge, Zeichenklassen, MFA-Pflicht) in der neuen
globalen Tabelle app_settings, durchgesetzt beim Anlegen, Zuruecksetzen und
Aendern von Passwoertern. Bestehende Passwoerter lassen sich nicht gegen eine
neue Richtlinie pruefen - der Hash gibt nichts her. Beim Anmelden liegt das
Passwort aber kurz im Klartext vor: dort wird geprueft und bei Verstoss ein
Wechsel verlangt, mit passendem Grund fuer den Hinweistext.

Nebenbei geschlossen: must_change_password war bisher nur im Frontend
erzwungen, wer die API direkt ansprach kam vorbei. enforce_account_state
haengt jetzt am /api-Sammelrouter und laesst nur noch durch, was man zum
Erfuellen der Pflicht braucht.

Das JSON-Backup liess sich bisher grundsaetzlich nicht zurueckladen: keine
Version, Kategorien nur ueber mehrdeutige Namen, sieben Tabellen fehlten.
Daneben steht nun ein Format v2, das Beziehungen ueber lokale IDs abbildet,
je Benutzer oder systemweit. Zurueckgeladen wird nach einer Pruefansicht,
wahlweise ersetzend oder ergaenzend; vor dem Ersetzen legt der Server einen
Schnappschuss der Datenbank an. Der alte Ansichts-Export bleibt fuer
Tabellenkalkulationen bestehen und wird beim Hochladen ausdruecklich
abgewiesen, statt halb zu raten.

Frontend: wiederverwendbares Passwortfeld mit Augensymbol, animierte
Anforderungsliste, 2FA-Seite, Admin-Karte fuer die Richtlinie und Karte zum
Zurueckladen. Neue Bewegung ist in prefers-reduced-motion hinterlegt; Secret
und Codes sind markierbar, sonst verhinderte das globale user-select das
Kopieren.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-20 10:11:22 +02:00

3.5 KiB

Raw Permalink Blame History

Backup & Wiederherstellung

In der App

Einstellungen → Backup & Export:

Voll-Backup (JSON) — alle eigenen Daten in einem versionierten Format, das sich in der App wieder einspielen lässt (siehe unten): Konten, Kategorien, Buchungen mit allen Feldern, Budget-Vorlage und Monatswerte, Schlagwortregeln, Import-Vorlagen, Dashboard-Layout und die persönlichen Einstellungen.
Buchungen (CSV/JSON) und Alle Daten (JSON) — Ansichts-Exporte zum Archivieren und Weiterverarbeiten, etwa in einer Tabellenkalkulation. Referenzen laufen dort über Namen und mehrere Tabellen fehlen: zum Wiederherstellen taugen sie nicht. Die App weist eine solche Datei beim Einspielen ausdrücklich ab, statt halb zu raten.
Komplettes DB-Backup (nur Admin) — lädt eine konsistente Kopie der gesamten SQLite-Datenbank herunter (alle Nutzer). Erzeugt über die SQLite-Online-Backup-API, also auch bei laufendem Betrieb gefahrlos.
Systemweites Voll-Backup (JSON) (nur Admin) — dasselbe JSON-Format über alle Benutzer hinweg, inklusive Benutzerkonten. Die Datei enthält Passwort-Hashes und Zwei-Faktor-Geheimnisse und ist wie ein Passwort zu behandeln.

Wiederherstellen (JSON, in der App)

Einstellungen → Backup zurückladen. Die Datei wird zuerst nur geprüft; die Prüfansicht zeigt, was darin steckt. Geschrieben wird erst nach Bestätigung.

Zwei Vorgehen:

Ersetzen — die vorhandenen Daten werden gelöscht und durch das Backup ersetzt. Vorher legt der Server automatisch einen Schnappschuss der Datenbank unter /var/lib/certain-finance/backups/pre-restore-*.db an.
Ergänzen — nichts wird gelöscht, nur Fehlendes kommt hinzu. Konten und Kategorien werden über den Namen abgeglichen, Buchungen über ihren Import-Hash beziehungsweise über Datum, Konto, Betrag und Empfänger. Budget, Regeln und Einstellungen bleiben unangetastet, wenn dazu schon etwas vorhanden ist — halb zusammengeführte Budgets wären nicht sinnvoll deutbar.

Ein systemweites Backup kann nur ein Admin einspielen, und nur ersetzend. Da dabei die Benutzertabelle ausgetauscht wird, enden anschliessend alle Sitzungen und man muss sich neu anmelden. Enthält die Datei keinen Administrator, wird sie abgelehnt — sonst käme danach niemand mehr hinein.

Das Einspielen läuft in einer einzigen Transaktion: entweder geht alles durch, oder es wird nichts geschrieben.

Wiederherstellen (DB-Backup)

Die heruntergeladene .db-Datei ist die komplette Datenbank. Zum Wiederherstellen im LXC:

systemctl stop certain-finance
cp certain-finance-YYYYMMDD-HHMMSS.db /var/lib/certain-finance/app.db
# WAL-/SHM-Reste entfernen, damit die Kopie sauber übernommen wird:
rm -f /var/lib/certain-finance/app.db-wal /var/lib/certain-finance/app.db-shm
chown certain-finance:certain-finance /var/lib/certain-finance/app.db 2>/dev/null || true
systemctl start certain-finance

Datei-Backup (LXC)

Die Datenbank liegt unter /var/lib/certain-finance/app.db.

Proxmox-Snapshot: vzdump des Containers sichert alles (empfohlen).
Cron-Kopie: täglich eine konsistente Kopie ablegen und rotieren:

# /etc/cron.daily/certain-finance-backup  (ausführbar machen)
#!/bin/sh
D=/var/lib/certain-finance
mkdir -p "$D/backups"
sqlite3 "$D/app.db" ".backup '$D/backups/app-$(date +\%Y\%m\%d).db'"
# älter als 30 Tage löschen
find "$D/backups" -name 'app-*.db' -mtime +30 -delete

update.sh legt außerdem vor jeder Migration automatisch eine Kopie unter /var/lib/certain-finance/backups/pre-update-*.db an.

3.5 KiB Raw Permalink Blame History