checks.webauthn_anchor meldete bisher nur, OB app.url oder
security.webauthn_rp_id einen Wert tragen. Das beantwortet die Frage
nicht, die dahintersteht: Ein Tippfehler in app.url weist den
Hardwarekey genauso ab wie ein fehlender Wert - der Browser traegt den
echten Ursprung in clientDataJSON ein, und der muss zu expectedOrigin
passen.
Die Pruefung vergleicht jetzt zusaetzlich mit dem Namen, unter dem die
Anfrage tatsaechlich hereinkam, und meldet configured und
matches_request getrennt. Dass dafuer der Host-Header herangezogen wird,
ist unbedenklich: Es ist eine Diagnose, keine Entscheidung. Wer ihn
faelscht, erzeugt eine falsche Warnung und sonst nichts - waehrend
WebauthnServer ihn weiterhin unveraendert ignoriert.
Damit ist die Auskunft vor einem Deployment belastbar, statt nur die
haelfte der Frage zu beantworten.
188 von 188 Testfaellen gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
