Schlüssel und Testumgebungen

Was Sie wissen müssen

Site-Key

32 alphanumerische Zeichen. Öffentlich: Er kommt in das Attribut data-site des Script-Tags. Das Dashboard zeigt ihn unter dem Namen « Identifiant public du site » (öffentliche Kennung der Website).

Verifizierungs-Secret

64 alphanumerische Zeichen. Es kommt in das Feld secret von /v1/siteverify, nur auf dem Server. Im Dashboard ist es ein Schlüssel mit der Verwendung « Vérification serveur » (Prüfung auf dem Server).

Dasselbe Secret dient, ohne Header Authorization, dazu, den tatsächlichen Ausgang eines Versuchs über /v1/feedback zu melden (siehe die Prüfung). Ein Test-Secret erhält dort die Antwort einer angenommenen Meldung, ohne dass etwas gespeichert wird.

Bewertungsschlüssel

Ebenfalls 64 Zeichen, mit der Verwendung « Évaluation (kit signé) » (Bewertung, signiertes Kit). Er dient dem Node-SDK, das mit seiner Dokumentation auf npm veröffentlicht werden wird; es ist noch nicht veröffentlicht. Er ist kein Verifizierungs-Secret: siteverify lehnt ihn mit invalid-input-secret ab, ebenso /v1/feedback ohne Header Authorization.

Erstellen, kopieren, widerrufen

• Tab « Clés » der Website, « Créer une clé » (Schlüssel erstellen): Wählen Sie die Umgebung (Production oder Test) und die Verwendung. Der Schlüssel wird nur einmal angezeigt, bei seiner Erstellung. Kopieren Sie ihn dann in Ihren Secret-Manager oder in Ihre Umgebungsvariablen.
• Die Liste zeigt danach die ersten vier Zeichen jedes Schlüssels, das Erstellungsdatum, die letzte Verwendung und den Zustand. Verlieren Sie ein Secret, erstellen Sie ein neues.
• « Révoquer » (Widerrufen) verlangt eine Bestätigung. Ein widerrufener Schlüssel wird innerhalb der folgenden 10 Sekunden abgelehnt (so lange hält Antisy die gültigen Schlüssel im Speicher): Die Prüfung antwortet dann invalid-input-secret.
• Antisy protokolliert ein Secret nie über seine ersten vier Zeichen hinaus.

Ein Secret ohne Unterbruch wechseln

1. Erstellen Sie ein neues Verifizierungs-Secret, ohne das alte zu widerrufen.
2. Setzen Sie es auf Ihrem Server ein.
3. Prüfen Sie, dass es funktioniert: Die « letzte Verwendung » des neuen Schlüssels wird aktualisiert.
4. Widerrufen Sie das alte.

Ist ein Secret nach aussen gelangt, widerrufen Sie es sofort: Ein widerrufenes Secret nützt niemandem mehr, und Sie erstellen ein neues.

Testschlüssel

Für eine Continuous Integration oder eine lokale Entwicklung stellt Antisy Dummy-Schlüssel und Dummy-Token bereit.

Dummy-Site-Keys

Zwei feste öffentliche Schlüssel, in der Form eines echten Site-Keys. Jeder liefert das Ergebnis seines Namens.

• allow: TestAllow00000000000000000000000
• deny: TestDeny000000000000000000000000

Test-Secret

Ein Schlüssel, erstellt mit der Umgebung « Test » und der Verwendung « Vérification serveur ». Eine Website hat höchstens 2 davon gleichzeitig. Er zählt nicht in den Statistiken. Die Testschlüssel der ganzen Organisation, über alle Websites, teilen sich 1’000 Aufrufe pro Tag (UTC-Tag) und, Stand heute, 2’500 pro Monat (UTC-Monat). Darüber: 429, bis zur nächsten Mitternacht UTC oder bis zum Ersten des nächsten UTC-Monats.

In einer Entwicklungsseite

Setzen Sie einen Dummy-Site-Key in das Attribut data-site des Script-Tags. Das Script durchläuft seinen ganzen Weg wie mit einem echten Schlüssel, und das Feld antisy-token wie auch antisy.token() erhalten das feste Token dieses Schlüssels. Ihr Server prüft es mit einem Test-Secret und erhält das Ergebnis des Dummy-Schlüssels.

• Kein Hostname zu deklarieren: Ein Dummy-Schlüssel hat keinen, und Antisy prüft derzeit die Origin der Seite für ihn nicht. localhost, 127.0.0.1 oder ein Staging-Server über HTTPS erhalten dasselbe Token. Ihre Produktionswebsite behält ihre Liste von Namen, ohne localhost.
• Das Token ist immer dasselbe, und öffentlich: Es sagt nichts über den Besucher. Was die Entwicklungsseite zeigt, ist, dass das Script läuft: Eine unvollständige CSP-Richtlinie zum Beispiel wird dort vor der Produktion sichtbar.

Ohne Browser (Continuous Integration)

Zuerst holt man ein festes Token, indem man bei einem Dummy-Site-Key hinterlegt, dann prüft man es mit einem Test-Secret. Die Hinterlegung erwartet weder ein Versuchs-Token noch eine Messung des Browsers: Ein beliebiger Umschlag, der mit ae2. beginnt, genügt, und die Antwort enthält das Token im Klartext.

# 1. Ein Test-Token: der Dummy-Site-Key « allow », ein beliebiger Umschlag.
TOKEN=$(curl -sS https://api.antisy.com/v1/collect \
  -H 'content-type: application/json' \
  -d '{"site":"TestAllow00000000000000000000000","envelope":"ae2.test"}' \
  | sed -n 's/.*"token":"\([^"]*\)".*/\1/p')

# 2. Seine Verifizierung, mit einem Test-Secret (über die Standardeingabe, nicht als Argument).
printf 'secret=%s' "$ANTISY_TEST_SECRET" | curl -sS https://api.antisy.com/v1/siteverify \
  -d @- \
  --data-urlencode response="$TOKEN"

Die Antwort trägt das Ergebnis des Dummy-Schlüssels, das Kennzeichen test_key, und nichts in challenge_ts, hostname und action, ob das feste Token aus der CI oder aus einer Seite stammt: Es wurde kein echtes Token hinterlegt.

{"success":true,"verdict":"allow","flags":["test_key"],"error-codes":[],"challenge_ts":null,"hostname":null,"action":null,"event_id":"evt_…"}

• Mit einem Produktions-Secret ist ein festes Token nur ein unbekanntes Token: invalid-input-response. Kein echter Verkehr kann also über sie durchkommen.

Setzen Sie nie einen Testschlüssel in der Produktion ein

Die festen Token sind öffentlich. Mit einem Test-Secret kann jeder das Token « allow » senden und wird angenommen: Ein Bot kommt damit durch. Ein Testschlüssel, der versehentlich in der Produktion steht, lässt also die Bots durch, ohne dass etwas sichtbar kaputtgeht.

• Das Dashboard kennzeichnet jeden Testschlüssel mit « Test », in der Liste wie bei der Erstellung, mit dieser Warnung.
• Erhält ein Testschlüssel Verkehr, der wie echter Verkehr aussieht, schreibt Antisy an die Warnadresse des Kontos (Einstellung « Adresse des alertes »), höchstens einmal pro Woche. Ohne hinterlegte Adresse wird keine Nachricht gesendet.
• Da kein Präfix sie unterscheidet, halten Sie Ihre Test-Secrets in Umgebungsvariablen, die entsprechend benannt und von denen der Produktion getrennt sind.
• Lassen Sie keinen Dummy-Schlüssel in data-site in der Produktion: Mit dem Produktions-Secret Ihrer Website gibt jedes feste Token invalid-input-response zurück, also wird jede Übermittlung abgelehnt.

Weiter geht es mit der Prüfung auf dem Server.