Warum es diesen Zugang überhaupt gibt
Szene 1 von 13
Bevor am 23. September ein Prüfer-Zugangscode angeglichen werden konnte, musste der Mechanismus selbst existieren. Er wurde zwei Tage vorher aus einer klaren Einschränkung gebaut, nicht ad hoc erfunden.
Erklärung
Lenn und Jakob, bevor wir zur Ablehnung kommen, schauen wir zwei Tage zurück. Eine App-Prüferin von Apple kann keine E-Mail empfangen, die an ein echtes Lernkonto geht. Die naheliegende Lösung — ein Passwort für dieses eine Konto — wäre eine neue, dauerhafte Schwachstelle gewesen. Stattdessen entstand ein eng begrenzter Zusatzweg: eine feste sechsstellige Ziffernfolge, gültig nur für eine Handvoll namentlich erlaubter Adressen, standardmäßig ausgeschaltet, und jede erfolgreiche Nutzung wird in ein eigenes Prüfprotokoll geschrieben. Kein neues Passwortfeld, kein Sonderpfad an der Kontenverwaltung vorbei — nur eine eng gefasste Ausnahme von der bestehenden Einmalcode-Prüfung, die sich selbst protokolliert. Der Beleg zeigt die erste Fassung vom 21. September; in den Folgetagen wurde der Mechanismus überarbeitet und der Code-Schlüssel heißt in den Belegen am Ablehnungstag `STUDY_REVIEW_OTP_CODE` statt des anfangs gehashten Werts. Beide Fassungen tragen dieselbe Grundidee: Zulassungsliste, feste Ziffernfolge, Prüfprotokoll. Öffnet den Beleg und prüft selbst, wo diese drei Stücke stehen.
Ein eng begrenzter, selbstprotokollierender Zusatzweg
- Zulassungsliste
- Genau eine namentlich erlaubte Adresse — keine offene Regel.
- Feste Ziffernfolge
- Kein neues Geheimnis-Feld im Datenmodell; dieselbe Codeform wie jeder Einmalcode.
- Selbstprotokollierung
- Jede erfolgreiche Nutzung erzeugt einen eigenen, durchsuchbaren Prüfeintrag.
Denkpause
Wäre ein einfaches, dauerhaftes Passwort für das Prüferkonto nicht schneller gewesen?
Ja, ein Passwort ist einfacher zu erklären.
Einfacher zu erklären, aber ein dauerhaftes Geheimnis mit unbegrenzter Gültigkeit ist ein größeres Risiko.
Nein — eine eng begrenzte, protokollierte Ausnahme ist kleiner als ein neues dauerhaftes Geheimnis.
Richtig. Die Grenze der Lösung sollte die Grenze des Problems widerspiegeln.
Nein, beide sind gleich riskant.
Zulassungsliste und Prüfprotokoll sind zwei zusätzliche, unabhängige Schranken.
Belege
Architekturentscheidung · ursprüngliche Fassung · später umbenannt · feat(leana): App Review reviewer fixed-code login
2026-09-21 · docs/lernbegleiter/engineering/adr-reviewer-login-2026-09-21.md · 6862cadc7dbdbd0171b9b92bd90323edcd120e3b
## Decision A **reviewer fixed-code login**, active only when configured: - `STUDY_REVIEWER_LOGIN_EMAIL` — exactly one allow-listed address (production env only). - `STUDY_REVIEWER_LOGIN_CODE_HASH` — SHA-256 hex of a fixed 6-digit code (never stored in plaintext). - `STUDY_REVIEWER_LOGIN_EXPIRES` — ISO-8601 expiry date after which the mechanism is inert. When the OTP verify route sees a challenge owned by the allow-listed address, it verifies the fixed code (constant-time) instead of the delivered OTP, then issues an ordinary session through the existing journal. Every use is rate-limited and audited (`auth.reviewer.attempt`). The code is inert when the env is unset or expired, and refuses any account whose role is above `student`. The account itself is operator-provisioned (see the seeding runbook): created as a `student`, assigned the Pécs pack, given an approved `pecs_verifications` row with a synthetic proof, and seeded with progress so Karten/a session/a timed practice test have content.
Mit meinem Konto im Hörsaal öffnen →