[Alpha]{class="badge informative"}

Authentifizierung

Der SDK-Server wird in einer vertrauenswürdigen Umgebung ausgeführt, die Sie steuern. Aus diesem Grund sendet es Ereignisse an die authentifizierte Edge Network-Server-API anstelle des nicht authentifizierten Endpunkts, den Browser verwenden. Authentifizierte Anfragen ermöglichen es dem Edge Network, den von Ihrem Server gesendeten Daten zu vertrauen.

Für die Authentifizierung benötigt die SDK OAuth-Server-zu-Server-Anmeldedaten von Adobe Developer Console. Sie können sie mithilfe der erforderlichen edgeCredentials-Option an configure übergeben. Die SDK verwendet die Berechtigung, um ein Zugriffstoken von Adobe anzufordern, und fügt dann das Token zu jeder authentifizierten Anfrage hinzu.

Erstellen von OAuth-Server-zu-Server-Anmeldedaten create-credential

Um eine Berechtigung zu erstellen, müssen Sie in Ihrem Unternehmen Entwickler und Anwender von Adobe Experience Platform sein. Führen Sie dann die folgenden Schritte aus:

Unter Authentifizieren und Zugreifen auf Experience Platform-APIs finden Sie detaillierte Anweisungen und Screenshots für jeden Schritt, einschließlich Informationen zum Erhalten von Entwickler- und Benutzerzugriff.

Konfigurieren der SDK mit Ihren -Anmeldeinformationen configure

Übergeben Sie die Werte, die Sie beim Aufruf von configure in die Option edgeCredentials kopiert haben. Lesen Sie sie aus Umgebungsvariablen oder aus einem Geheimnis-Manager, anstatt sie im Quell-Code zu platzieren.

await alloy.configure({
  datastreamId: "ebebf826-a01f-4458-8cec-ef61de241c93",
  orgId: "ADB3LETTERSANDNUMBERS@AdobeOrg",
  edgeCredentials: {
    clientId: process.env.ADOBE_CLIENT_ID,
    clientSecret: process.env.ADOBE_CLIENT_SECRET,
    scopes: process.env.ADOBE_SCOPES.split(",")
  }
});

Wenn Sie edgeCredentials auslassen, wird configure mit einem Fehler zurückgewiesen. Siehe edgeCredentials für die vollständige Liste der Eigenschaften.

Verwenden Sie dieselbe Organisation für die Anmeldedaten und die orgId. Der SDK sendet orgId in der x-gw-ims-org-id-Kopfzeile jeder authentifizierten Anfrage.

Welche Anfragen authentifiziert werden authenticated-requests

Nur sendEvent verwendet die authentifizierte Server-API. Die Server-API stellt keine äquivalenten Endpunkte für Identitäts- und Einverständnisanfragen bereit, sodass diese Methoden nicht authentifizierte Anfragen an den standardmäßigen Edge Network-Endpunkt senden, genau wie Web SDK es tut. Die SDK wählt den Endpunkt für Sie aus.

Wenn thirdPartyCookiesEnabled true ist (der Standard), wird die erste nicht authentifizierte Anfrage eines Besuchers an adobedc.demdex.net statt an den edgeDomain gesendet.

Jede authentifizierte Anfrage enthält die folgenden Kopfzeilen:

Festlegen des Zugriffstyps auf einen Datenstrom datastream-access-type

Datenströme verfügen über eine Einstellung Zugriffstyp die steuert, ob die Edge Network nicht authentifizierte Anfragen akzeptiert. Siehe Konfigurieren erweiterter Optionen im Handbuch zu Datenströmen.

Primäre Identität in Ereignisse einschließen primary-identity

Die Edge Network kann keine Cookies aus dem Browser des Besuchers auf einer Server-zu-Server-Anfrage lesen. Aus diesem Grund muss jedes Ereignis, das die Server-API erhält, eine primäre Identität in der identityMap des Ereignisses enthalten. Wenn ein Ereignis kein solches enthält, wird es vom Edge Network mit dem Fehlercode EXEG-0306-400 zurückgewiesen.

await visitor.sendEvent({
  xdm: {
    eventType: "web.webpagedetails.pageViews",
    identityMap: {
      Email: [{ id: "visitor@example.com", primary: true }]
    }
  }
});

Weitere Informationen finden Sie unter xdm .

Zugriffstoken-Caching token-caching

Die SDK fordert beim ersten Senden einer authentifizierten Anfrage ein Zugriffstoken von Adobe Identity Management Service (IMS) an, nicht beim Aufruf von configure. Das Token wird dann bis fünf Minuten vor Ablauf des Tokens wiederverwendet. Jedes forRequest-Handle, das eine Instanz erstellt, teilt ein zwischengespeichertes Token. Die Instanz der obersten Ebene speichert ihr eigenes Token separat zwischen, was nur von Bedeutung ist, wenn Sie auch Ereignisse direkt von ihr senden. Zugriffs-Token sind etwa 24 Stunden lang gültig. Ein ausgelasteter Server fordert daher etwa einmal täglich ein neues Token an, anstatt einmal pro Besucher.

Wenn mehrere Anfragen ein Token gleichzeitig benötigen, nutzen sie eine einzige Token-Anfrage. Wenn die Token-Anfrage fehlschlägt, z. B. weil das Client-Geheimnis falsch ist, lehnt die Methode, die sie ausgelöst hat, mit einem Fehler ab, dessen Nachricht Failed to acquire an IMS access token enthält.

Schützen von Anmeldeinformationen protect-credentials

Das Client-Geheimnis gewährt Zugriff auf die Daten Ihrer Organisation. Befolgen Sie die folgenden Vorgehensweisen:

Der SDK redigiert das Client-Geheimnis und ersetzt es durch [REDACTED], in seinen Debug-Protokollen und in der Konfiguration, die getLibraryInfo zurückgibt.