govoplan-access/docs/PASSWORD_RECOVERY_POSTGRES_TESTS.md

Password recovery: PostgreSQL concurrency verification

English

tests/test_password_recovery_postgres.py contains four optional real-transaction regressions: simultaneous redemption of one recovery code, simultaneous changes using one old password/session, competing recovery-code issuance, and issuer password revocation during redemption. They reuse the synthetic Access HTTP fixture with real PostgreSQL account locks and compare-and-swap updates.

Provision a disposable test database, preferably in a temporary PostgreSQL cluster with only a private Unix socket. Never use a production or shared development database. The supplied role needs permission to create and drop schemas. The tests create a random access_password_race_* schema per case and drop only that schema afterward, including on test failure. Audit emission is mocked as in the ordinary fixture; these are not audit-sink integration tests.

From the Access checkout, using the workspace Python environment with the current Core/Access sources, pytest, and psycopg installed:

GOVOPLAN_ACCESS_TEST_POSTGRES_URL='postgresql+psycopg://test_role@/disposable_test?host=/absolute/private/socket&port=55439' \
  ../govoplan/.venv/bin/python -m pytest -q tests/test_password_recovery_postgres.py

Replace the synthetic URL with the explicitly provisioned test fixture. Without this variable all four tests are skipped; there is no fallback to application database settings. The tests do not provision or stop PostgreSQL: the fixture owner must stop its temporary cluster and verify cleanup after the run. Existing portable password-recovery tests continue to run without PostgreSQL.

Deutsch

tests/test_password_recovery_postgres.py enthält vier optionale Regressionstests mit echten Transaktionen: gleichzeitige Einlösung desselben Wiederherstellungscodes, gleichzeitige Änderungen mit demselben alten Passwort und derselben Sitzung, konkurrierende Code-Ausstellung sowie Passwortwechsel des ausstellenden Administrators während einer Einlösung. Die synthetische Access-HTTP-Testumgebung nutzt dabei echte PostgreSQL-Kontosperren und bedingte Datenbankaktualisierungen.

Nur eine wegwerfbare Testdatenbank verwenden, möglichst in einem temporären PostgreSQL-Cluster mit privatem Unix-Socket. Produktionsdatenbanken und gemeinsam genutzte Entwicklungsdatenbanken sind ausgeschlossen. Die Testrolle benötigt Berechtigungen zum Erstellen und Löschen von Schemas. Jeder Test erstellt ein zufälliges Schema access_password_race_* und entfernt ausschließlich dieses Schema auch bei Fehlern. Die Audit-Ausgabe bleibt wie im bestehenden Testaufbau simuliert; ein externer Audit-Dienst wird damit nicht geprüft.

Der obige Aufruf gilt aus dem Access-Checkout mit der aktuellen Workspace-Python-Umgebung. Die Beispiel-URL muss durch die ausdrücklich bereitgestellte Testumgebung ersetzt werden. Ohne GOVOPLAN_ACCESS_TEST_POSTGRES_URL werden alle vier Tests übersprungen; es gibt keinen Rückgriff auf die Datenbankeinstellungen der Anwendung. Die Tests starten und stoppen PostgreSQL nicht selbst: Der Betreiber der Testumgebung muss den temporären Cluster anschließend stoppen und die Bereinigung prüfen. Die bestehenden portablen Tests laufen weiterhin ohne PostgreSQL.