Échec de l’authentification des pièces jointes SAS de l’objet Blob Azure Campaign

La préparation d’une diffusion Adobe Campaign peut échouer lorsqu’une diffusion utilise un fichier de stockage Blob Azure référencé par une URL HTTPS signée SAS. L’URL peut fonctionner correctement dans un navigateur ou avec une URL, mais échouer lorsque Campaign récupère la pièce jointe pendant la préparation de la diffusion.

Description description

Pendant la préparation de la diffusion, Campaign tente de télécharger une pièce jointe depuis le stockage Blob d’Azure et renvoie une erreur d’authentification HTTP 403 :

La requête HTTP a renvoyé un ‘Server n’a pas pu authentifier la requête.
Assurez-vous que la valeur de l’en-tête d’autorisation est correctement forméey compris la signature.’ erreur de type.

*Le problème peut se produire même lorsque : L’URL d’objet Blob d’Azure fonctionne dans un navigateur web.

• La même URL fonctionne avec curl lorsqu’elle est correctement citée.
• Le point d’entrée Blob d’Azure a été placé sur la liste autorisée au niveau MID.
• Le problème se reproduit à la fois dans l’évaluation et la production.
• L’URL SAS apparaît correctement formatée dans les journaux Campaign.Dans certaines variantes, la saisie manuelle d’une URL avec échappement XML peut entraîner une erreur HTTP 409, telle que PublicAccessNotPermitted.L’impact commercial est que la préparation de la diffusion échoue avant l’envoi, ce qui bloque les diffusions e-mail qui dépendent des pièces jointes hébergées dans Azure.## Résolution resolution**

Cause première

Le problème est dû au recodage par Campaign de l’URL de pièce jointe distante avant l’envoi de la requête HTTP.Les URL SAS d’Azure contiennent généralement des caractères codés en pourcentage dans la signature, tels que :%2B
%3DCampaign code à nouveau l’URL pendant l’opération de récupération des pièces jointes. Par conséquent, les caractères déjà codés peuvent devenir codés en double :Valeur d’origine : %2B
Valeur envoyée : %252BAzure reçoit ensuite une valeur de signature différente de celle utilisée pour générer le jeton SAS. Comme la signature ne correspond plus, Azure rejette la demande avec un échec d’authentification.La représentation & versus & n’est pas la cause sous-jacente lorsque Campaign traite l’URL normalement. La sérialisation XML peut représenter une esperluette sous la forme &, et Campaign peut la supprimer. Cependant, la saisie manuelle de & dans l’URL peut entraîner une interprétation incorrecte des séparateurs de requêtes et une réponse 409 au lieu de l’erreur d’authentification SAS attendue.Le fait de placer sur la liste autorisée une URL ne résout pas le problème, car la requête atteint Azure mais contient une signature SAS modifiée ou non valide.L’enquête a également déterminé que l’utilisation d’une URL SAS Blob Azure distante en tant que pièce jointe récupérée dynamiquement est un écart d’utilisation non documenté pour ce scénario de diffusion.

Résolution

*L’approche recommandée et prise en charge consiste à télécharger le fichier Azure Blob sur le serveur Campaign avant que la diffusion ne soit préparée. Récupérez le fichier dans le workflow à l’aide d’un mécanisme de transfert de fichier approprié ou d’une activité JavaScript qui appelle l’API Blob d’Azure.

• Stockez le fichier sur le serveur Campaign.
• Configurez la pièce jointe de la diffusion pour référencer le chemin d’accès local au fichier côté serveur.
• Exécutez une diffusion test pour vérifier que le fichier est disponible lors de la préparation de la diffusion.Cela évite le comportement de recodage des URL distantes de Campaign et suit le modèle de pièce jointe serveur-local.**