solveChallenge() bereit — einen synchronen, serverseitigen Solver —, der das Schreiben automatisierter Tests für deine Challenge- und Verify-Endpunkte ohne Browser einfach macht. Statt einen Headless-Browser zu starten oder internen Zustand zu mocken, kannst du den vollständigen Zyklus Challenge → Solve → Verify direkt aus deiner Test-Suite heraus steuern.
solveChallenge in Tests verwenden
solveChallenge führt denselben Proof-of-Work-Algorithmus aus, den der Browser verwendet, jedoch synchron und in Node.js. Du kannst eine Challenge auf deinem Server generieren, sie wie ein Client lösen und das Ergebnis dann an verifySolution übergeben — alles innerhalb eines einzigen Tests.
Testen mit Timeout-Sicherungen
Wenn du in CI ein Sicherheitsnetz gegen einen außer Kontrolle geratenen Solver benötigst, übergibsolveChallenge Guardrail-Optionen. Du kannst die Wanduhrzeit, die Anzahl der Hash-Versuche oder beides begrenzen.
solveChallenge für dieses Token undefined zurück. Dein Test sollte vor der Übergabe an verifySolution prüfen, dass der Rückgabewert definiert ist.
Replay-Schutz testen
Ribaunts Standardmoduslocal für Replay-Schutz verhindert, dass ein Token innerhalb desselben Prozesses mehr als einmal verifiziert wird. Du kannst dieses Verhalten direkt in deinen Tests bestätigen, indem du dieselbe Lösung zweimal einreichst.
false zurück, weil die Challenge-JTIs beim ersten Gebrauch verbraucht werden.
Testen mit deaktiviertem Replay-Schutz
Einige Unit-Tests müssen dieselben Tokens über mehrere Assertions hinweg wiederverwenden — etwa um zu testen, dass eine gültige Lösung deine Geschäftslogik unabhängig vom Replay-Zustand immer besteht. Du kannst den Replay-Schutz für einen einzelnenverifySolution-Aufruf deaktivieren.
Verwende
replayPrevention: 'disabled' nur in Tests. Deaktiviere den Replay-Schutz niemals in deinem Produktions-Verify-Endpunkt, da Angreifer dadurch abgefangene Lösungen wiederverwenden können.Verifizierungs-Warnungen erfassen
Wenn du prüfen möchtest, warum eine Verifizierung fehlgeschlagen ist — nicht nur, dass siefalse zurückgegeben hat —, verwende den onWarning-Callback. Das ist besonders nützlich, um Randfälle wie abgelaufene Tokens oder ungültige Lösungen zu testen.
reason-Feld am Warning-Objekt kann einen der folgenden Werte annehmen:
| Grund | Wann er ausgelöst wird |
|---|---|
invalid-token | Das JWT ist fehlerhaft, manipuliert oder verwendet ein unbekanntes Secret |
expired-token | Die TTL der Challenge ist abgelaufen, bevor die Lösung eingereicht wurde |
invalid-solution | Der eingereichte Nonce erzeugt keinen Hash mit der erforderlichen Anzahl führender Nullen |
replay-detected | Dieselbe Token-JTI wurde bereits vom Replay-Store konsumiert |
configuration-error | Eine erforderliche Option (z. B. replayStore) fehlt oder ist falsch konfiguriert |