Errores de autenticación de datos adjuntos SAS de Azure Blob de Campaign

La preparación de la entrega de Adobe Campaign puede fallar cuando una entrega utiliza un archivo de almacenamiento de Azure Blob al que hace referencia una URL HTTPS firmada con SAS. La URL puede funcionar correctamente en un explorador o con curl, pero fallar cuando Campaign recupera el archivo adjunto durante la preparación de la entrega.

Descripción description

Durante la preparación de la entrega, Campaign intenta descargar un archivo adjunto del almacenamiento del blob de Azure y devuelve un error de autenticación HTTP 403:

La consulta HTTP devolvió un mensaje ‘El servidor no pudo autenticar la solicitud.
Asegúrese de que el valor del encabezado Autorización esté correctamente formadoincluida la firma.’ error de tipo.

*El problema puede producirse incluso cuando: La URL del blob de Azure funciona en un explorador web.

• La misma URL funciona con curl cuando se cita correctamente.
• El extremo del blob de Azure se ha incluido en la lista de permitidos en el nivel MID.
• El problema se reproduce en los entornos de ensayo y producción.
• La URL de SAS aparece con el formato correcto en los registros de Campaign.En algunas variaciones, la introducción manual de una dirección URL de escape XML puede provocar un error HTTP 409 como PublicAccessNotPermitted.El impacto comercial es que la preparación de envíos falla antes de enviarlos, lo que bloquea los envíos de correo electrónico que dependen de archivos adjuntos alojados en Azure.## Resolución resolution**

Causa raíz

El problema se debe a que Campaign vuelve a codificar la URL del archivo adjunto remoto antes de enviar la solicitud HTTP.Las direcciones URL de SAS de Azure suelen contener caracteres con codificación porcentual en la firma, como:%2B
%3DCampaign vuelve a codificar la dirección URL durante la operación de recuperación de archivos adjuntos. Como resultado, los caracteres ya codificados pueden convertirse en codificados dobles:Valor original: %2B
Valor enviado: %252BA continuación, Azure recibe un valor de firma diferente del que se utilizó para generar el token SAS. Como la firma ya no coincide, Azure rechaza la solicitud con un error de autenticación.La representación “y contra” no es la causa subyacente cuando Campaign procesa la dirección URL normalmente. La serialización XML puede representar un signo & y Campaign no puede omitirlo. Sin embargo, si se introduce & manualmente en la dirección URL, los separadores de consultas pueden interpretarse incorrectamente y dar lugar a una respuesta 409 en lugar del error de autenticación SAS esperado.La inclusión en la lista de permitidos de URL no resuelve el problema porque la solicitud llega a Azure pero contiene una firma SAS modificada o no válida.La investigación también determinó que el uso de una URL de Azure Blob SAS remota como un archivo adjunto recuperado dinámicamente es una brecha de uso no documentada para este escenario de entrega.

Resolución

*El método recomendado y admitido es descargar el archivo Azure Blob en el servidor de Campaign antes de preparar la entrega. Recupere el archivo dentro del flujo de trabajo mediante un mecanismo de transferencia de archivos adecuado o una actividad de JavaScript que llame a la API de Azure Blob.

• Almacene el archivo en el servidor de Campaign.
• Configure los archivos adjuntos de la entrega para que hagan referencia a la ruta de archivo local del lado del servidor.
• Ejecute un envío de prueba para comprobar que el archivo está disponible durante la preparación de la entrega.Esto evita el comportamiento de recodificación de la URL remota de Campaign y sigue el patrón de archivos adjuntos local del servidor.**