Token nur noch gehasht in Consumers.verificationCode
Der von send-portal-invite geminteten Einladungs-Token wurde im KLARTEXT in
die Consumer-Zeile geschrieben. Wer die Datenbank lesen kann, konnte damit
jeden offenen Einladungs-Link uebernehmen (Passwort setzen = Konto-
Uebernahme). Dieselbe Fehlerklasse wie storeevent-persistiert-rohen-reset-
token (behoben 2026-08-20).
Neu: hashPortalInviteToken = sha256(token) hex; nur der Digest geht in die
Zeile. Der Roh-Token verlaesst diesen Prozess ausschliesslich in
setPasswordUrl, also in der Mail.
🔴 AUSBRINGUNGS-REIHENFOLGE, nicht optional: clients/consumer-app MUSS
ZUERST live sein. Sein Leser ist beidseitig (Hash zuerst, Roh-Wert als
Uebergangs-Rueckfall). Geht dieses Repositorium zuerst raus, schreibt es
Hashes, waehrend der alte Leser nur den Klartext kennt — jede neue
Einladung waere unaufloesbar, ohne Fehlermeldung.
⚠ ZWILLING: dieselbe Funktion liegt in
clients/consumer-app/src/routes/data-fetcher.ts, genau wie
mintPortalInviteToken schon vorher. Laufen sie auseinander, findet der
Nachschlag einfach nichts — kein Fehler, kein Protokolleintrag. Beide
Proben-Reihen nageln denselben fest verdrahteten Digest fest; das ist die
einzige Stelle, an der eine Abweichung auffaellt.
Die zwei bestehenden Proben, die verificationCode auf /^pi-/ pruefen, sind
auf den neuen Vertrag umgestellt — sie hielten das alte, unsichere Verhalten
fest und wurden von dieser Aenderung erwartungsgemaess rot (der Diff zeigte
den Digest an der Stelle des pi-Tokens). Fuenf neue Proben dazu.
22/22 gruen, tsc --noEmit Exit 0.
⚠ Scoped Commit: der Arbeitsbaum trug zugleich 227 fremde Dateien aus einem
laufenden Codegen-Lauf. Sie sind NICHT Teil dieses Commits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
die Consumer-Zeile geschrieben. Wer die Datenbank lesen kann, konnte damit
jeden offenen Einladungs-Link uebernehmen (Passwort setzen = Konto-
Uebernahme). Dieselbe Fehlerklasse wie storeevent-persistiert-rohen-reset-
token (behoben 2026-08-20).
Neu: hashPortalInviteToken = sha256(token) hex; nur der Digest geht in die
Zeile. Der Roh-Token verlaesst diesen Prozess ausschliesslich in
setPasswordUrl, also in der Mail.
🔴 AUSBRINGUNGS-REIHENFOLGE, nicht optional: clients/consumer-app MUSS
ZUERST live sein. Sein Leser ist beidseitig (Hash zuerst, Roh-Wert als
Uebergangs-Rueckfall). Geht dieses Repositorium zuerst raus, schreibt es
Hashes, waehrend der alte Leser nur den Klartext kennt — jede neue
Einladung waere unaufloesbar, ohne Fehlermeldung.
⚠ ZWILLING: dieselbe Funktion liegt in
clients/consumer-app/src/routes/data-fetcher.ts, genau wie
mintPortalInviteToken schon vorher. Laufen sie auseinander, findet der
Nachschlag einfach nichts — kein Fehler, kein Protokolleintrag. Beide
Proben-Reihen nageln denselben fest verdrahteten Digest fest; das ist die
einzige Stelle, an der eine Abweichung auffaellt.
Die zwei bestehenden Proben, die verificationCode auf /^pi-/ pruefen, sind
auf den neuen Vertrag umgestellt — sie hielten das alte, unsichere Verhalten
fest und wurden von dieser Aenderung erwartungsgemaess rot (der Diff zeigte
den Digest an der Stelle des pi-Tokens). Fuenf neue Proben dazu.
22/22 gruen, tsc --noEmit Exit 0.
⚠ Scoped Commit: der Arbeitsbaum trug zugleich 227 fremde Dateien aus einem
laufenden Codegen-Lauf. Sie sind NICHT Teil dieses Commits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>