[Alpha]{class="badge informative"}

Authentification

Le SDK du serveur s’exécute dans un environnement approuvé que vous contrôlez. Pour cette raison, il envoie des événements à l’API du serveur Edge Network authentifiée au lieu du point d’entrée non authentifié utilisé par les navigateurs. Les requêtes authentifiées permettent à Edge Network d’approuver les données envoyées par votre serveur.

Pour l’authentification, le SDK a besoin d’informations d’identification de serveur à serveur OAuth de Adobe Developer Console. Vous le transmettez à configure à l’aide de l’option edgeCredentials , qui est obligatoire. Le SDK utilise les informations d’identification pour demander un jeton d’accès à Adobe, puis ajoute le jeton à chaque demande authentifiée.

Création d’informations d’identification de serveur à serveur OAuth create-credential

Pour créer des informations d’identification, vous devez être développeur et utilisateur de Adobe Experience Platform au sein de votre organisation. Effectuez ensuite les étapes suivantes :

Consultez ​ Authentification et accès aux API Experience Platform ​ pour obtenir des instructions détaillées et des captures d’écran pour chaque étape, y compris la manière d’obtenir un accès développeur et utilisateur.

Configuration du SDK avec vos informations d’identification configure

Transmettez les valeurs que vous avez copiées à l’option edgeCredentials lors de l’appel de configure. Lisez-les à partir de variables d’environnement ou d’un gestionnaire de secrets au lieu de les placer dans le code source.

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(",")
  }
});

Si vous omettez edgeCredentials, configure est rejeté avec une erreur. Voir edgeCredentials pour obtenir la liste complète des propriétés.

Utilisez la même organisation pour les informations d’identification et l’option orgId. Le SDK orgId envoie dans l’en-tête x-gw-ims-org-id de chaque requête authentifiée.

Les requêtes authentifiées authenticated-requests

Seul sendEvent utilise l’API du serveur authentifié. L’API du serveur ne fournit pas de points d’entrée équivalents pour les requêtes d’identité et de consentement. Ces méthodes envoient donc des requêtes non authentifiées au point d’entrée Edge Network standard, de la même manière que le fait Web SDK. Le SDK choisit le point d’entrée à votre place.

Lorsque la thirdPartyCookiesEnabled est true, qui est la valeur par défaut, la première demande non authentifiée d’un visiteur est envoyée à adobedc.demdex.net au lieu de la edgeDomain.

Chaque requête authentifiée comprend les en-têtes suivants :

Définir le type d’accès au flux de données datastream-access-type

Les flux de données ont un paramètre Type d’accès qui contrôle si Edge Network accepte les requêtes non authentifiées. Voir Configurer les options avancées dans le guide des flux de données.

Inclure une identité principale dans les événements primary-identity

Edge Network ne peut pas lire les cookies à partir du navigateur du visiteur dans une requête de serveur à serveur. Pour cette raison, chaque événement que l’API du serveur reçoit doit inclure une identité principale dans le identityMap de l’événement. Si un événement n’en inclut pas, Edge Network le rejette avec le code d’erreur EXEG-0306-400.

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

Voir xdm pour plus d’informations.

Mise en cache du jeton d’accès token-caching

Le SDK demande un jeton d’accès au service Adobe Identity Management Service (IMS) la première fois qu’il envoie une demande authentifiée, et non lorsque vous appelez configure. Il réutilise ensuite le jeton jusqu’à cinq minutes avant son expiration. Chaque gestion de forRequest créée par une instance partage un jeton mis en cache. L’instance de niveau supérieur met en cache son propre jeton séparément, ce qui importe uniquement si vous envoyez également directement des événements à partir de celle-ci. Les jetons d’accès sont valides pendant environ 24 heures. Par conséquent, un serveur occupé demande un nouveau jeton environ une fois par jour au lieu d’une fois par visiteur.

Si plusieurs requêtes ont besoin d’un jeton en même temps, elles partagent une seule requête de jeton. Si la requête de jeton échoue, par exemple parce que le secret client est erroné, la méthode qui l’a déclenchée est rejetée avec une erreur dont le message inclut Failed to acquire an IMS access token.

Protéger vos informations d’identification protect-credentials

Le secret client accorde l’accès aux données de votre organisation. Procédez comme suit :

Le SDK rédige le secret client, le remplaçant par [REDACTED], dans ses journaux de débogage et dans la configuration que getLibraryInfo renvoie.