Einstellungen für Verifizierungen
Der Tab General der Seite Configure legt fest, wie sich jede Verifizierung in Ihrem Workspace verhält. Dort steuern Sie, wie lange ein Code gültig bleibt, nach wie vielen falschen Versuchen eine Verifizierung endet, wie bald ein neuer Code gesendet werden kann und zu welcher Website der Code gehört.
Jedes Feld zeigt den wirksamen Wert: Ihren eigenen Wert, wenn Sie einen festgelegt haben, andernfalls den Plattform-Standardwert von Bird. Ein Feld wird gespeichert, sobald Sie es verlassen. Duration, Maximum Retries und Website werden beim Erstellen einer Verifizierung festgelegt, daher gilt eine Änderung nur für neue Verifizierungen. Eine Änderung von Retry Delay gilt ab dem nächsten Create-Aufruf, auch für eine bereits laufende Verifizierung.
Um eine Einstellung zu ändern, benötigen Sie die Berechtigung verify_management auf der Ebene write, die in den Rollen admin und developer enthalten ist. Die Rolle analyst kann die Seite ansehen. Siehe Benutzer, Teams und Rollen.

Ablauf einer Verifizierung
| Einstellung | Was sie steuert | Standardwert | Bereich |
|---|---|---|---|
| Duration | Wie lange eine Verifizierung offen bleibt. Eine Prüfung nach Ablauf dieses Zeitfensters liefert den Grund expired, und die Verifizierung endet mit dem Grund ttl_elapsed. | 10 Minuten | 1 bis 999 Minuten |
| Maximum Retries | Nach wie vielen falschen Codes eine Verifizierung endet. Der letzte falsche Code lässt sie mit dem Grund attempts_exhausted fehlschlagen. | 5 | 1 bis 10 |
| Retry Delay | Die Wartezeit für erneutes Senden: die Mindestwartezeit, bevor ein weiterer Code an denselben Empfänger gesendet wird. | 60 Sekunden | 0 bis 3.600 Sekunden |
- Duration beginnt, sobald die Verifizierung erstellt wird. Ein erneutes Senden oder ein Wechsel auf einen anderen Kanal sendet einen neuen Code, behält aber den ursprünglichen Ablaufzeitpunkt bei. Ein spätes erneutes Senden verlängert das Zeitfenster also nicht. Halten Sie den Wert für Authentifizierungsabläufe bei höchstens 10 Minuten; die Best Practices erklären, warum.
- Maximum Retries zählt falsche Codes über alle Codes hinweg, die für die Verifizierung gesendet wurden. Ein erneutes Senden setzt den Wert also nicht zurück. Wenn eine Prüfung mit einem falschen Code die Verifizierung offen lässt, meldet sie die verbleibenden Versuche in
attempts_remaining. - Retry Delay greift, wenn Sie für denselben Empfänger erneut create aufrufen. Innerhalb der Wartezeit gibt der Aufruf die laufende Verifizierung zurück, ohne einen neuen Code zu senden. Den Code über einen anderen Kanal senden ist davon ausgenommen, weil ein Kanalwechsel eine andere Anfrage ist als die erneute Anforderung desselben Kanals. Setzen Sie den Wert auf 0, um bei jedem create-Aufruf einen neuen Code zu senden, innerhalb der Limits pro Empfänger aus Abuse guardrails.
Die Codelänge legen Sie nicht auf dieser Seite fest. Codes bestehen standardmäßig aus sechs Ziffern, und options.code_length legt für eine einzelne Verifizierung 4 bis 8 Ziffern fest; siehe Optionen.
Automatisches Ausfüllen
Website gibt die Website an, auf der Ihre Nutzer ihre Codes eingeben, etwa https://login.example.com. Ist eine Website festgelegt, können Browser den Code auf dieser Website und auf keiner anderen anbieten. Der Nutzer muss den Code dann nicht kopieren. Lassen Sie das Feld leer, um Codes ohne Angabe einer Website zu senden.
Geben Sie die Website als https:// gefolgt von der Domain in Kleinbuchstaben an, ohne Port, Pfad oder abschließenden Schrägstrich. Eine internationalisierte Domain verwenden Sie in ihrer xn---Form, zum Beispiel https://xn--bcher-kva.example für bücher.example. Jede andere Form wird abgelehnt, und die Fehlermeldung nennt die einzugebende Form, sofern es eine gibt. Verwenden Sie genau die Website, auf der das Codefeld angezeigt wird: Ein Formular auf login.example.com benötigt https://login.example.com, nicht https://example.com.
Sobald eine Verifizierung eine Website hat, fügt Verify sie den Code-Nachrichten hinzu:
- SMS: Die Nachricht endet mit einer Zeile wie
@login.example.com #123456. Kennzeichnen Sie Ihr Codeeingabefeld mitautocomplete="one-time-code", damit Safari und andere Browser den Code anbieten, und rufen Sie auf der Seite die WebOTP API auf, wenn der Browser den Code ohne Antippen einfügen soll. Die zusätzliche Zeile kann ein weiteres SMS-Segment erfordern: In vielen Sprachen mit Unicode-Kodierung, etwa Arabisch, Griechisch oder Russisch, belegt ein gebundener Code zwei Segmente statt einem, was die SMS-Kosten verdoppelt. Eine lange Domain kann in anderen Sprachen dieselbe Wirkung haben. - E-Mail: Die Nachricht enthält einen
OTP-Token-Header mit dem Code und der Website, wie im OTP-Token Internet-Draft, Revision 01 definiert. E-Mail-Programme beginnen erst, diesen Header auszuwerten. Behandeln Sie ihn daher als Ergänzung zum Code in der Nachricht.
Die Website wird beim Erstellen einer Verifizierung festgelegt. Ein erneutes Senden, ein Fallback auf einen anderen Kanal oder ein weiterer create-Aufruf für denselben Empfänger behält sie bei.
Code pro Anfrage an eine Website binden
Eine Anfrage kann mit options.autofill_origin eine eigene Website angeben, die Website für diese Verifizierung ersetzt. Nutzen Sie dies, wenn ein Workspace mehrere Websites bedient.
Wenn das Codefeld in einem Cross-Origin-iframe liegt, etwa in einem Zahlungsformular, das in den Checkout eines Shops eingebettet ist, setzen Sie options.autofill_origin auf die Website des iframes und options.autofill_top_level_origin auf die Seite im Browser-Tab. Die SMS-Zeile nennt dann beide Websites, wie in @shop.example #123456 @pay.example, was in jeder Sprache ein Segment hinzufügen kann. Chrome füllt dieses Formular automatisch aus, wenn die Seite das iframe direkt einbettet und ihm allow="otp-credentials" gewährt. E-Mails enthalten bei diesen Verifizierungen keinen OTP-Token-Header, da der Header nur eine Website nennen kann. Die Anfrage wird mit 422 abgelehnt, wenn die Top-Level-Website fehlerhaft ist, wenn weder in der Anfrage noch auf dieser Seite eine Website festgelegt ist oder wenn sie mit dieser Website übereinstimmt.
Registrierte SMS-Absender
Wenn Sie SMS über Ihren eigenen registrierten Absender senden, etwa eine US-10DLC-Kampagne, fügen Sie der Kampagne eine Beispielnachricht mit der gebundenen Zeile am Ende hinzu, bevor Sie eine Website festlegen. Netzbetreiber können Nachrichten filtern, die von den registrierten Beispielen der Kampagne abweichen.
Fehlerbehebung
- Die Website wird abgelehnt. Der Wert hat nicht das erforderliche Format. Geben Sie das Format ein, das die Meldung vorschlägt, zum Beispiel
https://example.comfürhttps://Example.com/. - Der Browser bietet den Code nicht an. Prüfen Sie, ob die Website exakt mit der Adresse der Seite übereinstimmt, einschließlich einer etwaigen Subdomain, und ob das Codefeld
autocomplete="one-time-code"hat. Prüfen Sie bei einem iframe, ob die Anfrage beide Websites festlegt und die einbettende Seiteallow="otp-credentials"gewährt. Das automatische Ausfüllen hängt auch vom Browser ab: Chrome liest die SMS-Zeile über WebOTP und Safari über seine eigene Code-Autofill-Funktion, während Firefox WebOTP nicht unterstützt (Browserunterstützung). - Ein Code ist abgelaufen, bevor der Nutzer ihn eingegeben hat. Prüfen Sie die zeitliche Abfolge der Versuche im Verify-Log, bevor Sie Duration erhöhen. Meist ist ein langsamer Zustellweg die Ursache, und ein längeres Zeitfenster schwächt den Code.
Nächste Schritte
- Verifizierungen senden: Verifizierungen erstellen und prüfen, einschließlich Optionen pro Anfrage.
- Ziele: Kanäle und deren Reihenfolge für jedes Zielland festlegen.
- Absender und Branding: die Nachrichten ansehen, die Verify sendet, und den Absender für jeden Kanal auswählen.
Verwandte Ressourcen
Weiter mit der Dokumentation, Anleitungen und Beispielen zu diesem Thema.