Campaign Azure Blob SAS 첨부 파일 인증 실패

게재에서 SAS 서명 HTTPS URL에 의해 참조되는 Azure Blob 저장소 파일을 사용하는 경우 Adobe Campaign 게재 준비가 실패할 수 있습니다. URL은 브라우저에서 또는 curl로 성공적으로 작동할 수 있지만, Campaign이 게재를 준비하는 동안 첨부 파일을 검색하면 실패합니다.

설명 description

게재를 준비하는 동안 Campaign은 Azure Blob 저장소에서 첨부 파일을 다운로드하고 HTTP 403 인증 오류를 반환합니다.

HTTP 쿼리에서 '서버가 요청을 인증하지 못했습니다.
인증 헤더의 값이 올바르게 구성되었는지 확인서명을 포함 유형 오류.

*이 문제는 다음과 같은 경우에도 발생할 수 있습니다. Azure Blob URL은 웹 브라우저에서 작동합니다.

• 올바르게 따옴표를 지정하면 curl에서 동일한 URL이 작동합니다.
• Azure Blob 끝점이 MID 수준에서 허용 목록에추가된으로 설정되었습니다.
• 스테이징과 프로덕션에서 모두 문제가 재현됩니다.
• SAS URL의 형식이 캠페인 로그에 올바르게 표시됩니다.일부 변형에서 XML 이스케이프 처리된 URL을 수동으로 입력하면 PublicAccessNotAllowed와 같은 HTTP 409 오류가 발생할 수 있습니다.비즈니스의 영향은 보내기 전에 게재 준비가 실패하여 Azure 호스팅 첨부 파일에 의존하는 이메일 게재가 차단된다는 것입니다.## 해결 방법 resolution**

근본 원인

이 문제는 Campaign이 HTTP 요청을 보내기 전에 원격 첨부 파일 URL을 다시 인코딩하기 때문에 발생합니다.Azure SAS URL은 일반적으로 다음과 같이 서명에 퍼센트 인코딩된 문자를 포함합니다.%2B
%3DCampaign은 첨부 파일 가져오기 작업 중에 URL을 다시 인코딩합니다. 따라서 이미 인코딩된 문자는 이중 인코딩이 될 수 있습니다.원래 값: %2B
보낸 값: %252B그런 다음 Azure은 SAS 토큰을 생성하는 데 사용되는 서명 값과 다른 서명 값을 받습니다. 서명이 더 이상 일치하지 않으므로 Azure은 인증 실패로 요청을 거부합니다.Campaign에서 URL을 정상적으로 처리할 때 & 대 & 표현은 근본 원인이 아닙니다. XML serialization은 앰퍼샌드를 & 로 나타낼 수 있으며 Campaign은 이 앰퍼샌드를 이스케이프 해제할 수 있습니다. 그러나 URL에 수동으로 & 를 입력하면 쿼리 구분 기호가 잘못 해석되고 예상 SAS 인증 오류 대신 409 응답이 나타날 수 있습니다.요청이 Azure에 도달하지만 수정되거나 잘못된 SAS 서명이 포함되어 있기 때문에 URL 허용 목록에 추가으로 문제가 해결되지 않습니다.또한 이 조사는 원격 Azure Blob SAS URL을 동적으로 검색된 첨부 파일로 사용하는 것이 이 게재 시나리오에 대한 미문서화된 사용 격차임을 확인했습니다.

해상도

*권장되고 지원되는 접근 방법은 게재를 준비하기 전에 Azure Blob 파일을 Campaign 서버에 다운로드하는 것입니다. 적절한 파일 전송 메커니즘 또는 Azure Blob API를 호출하는 JavaScript 활동을 사용하여 워크플로우 내에서 파일을 검색합니다.

• Campaign 서버에 파일을 저장합니다.
• 로컬 서버측 파일 경로를 참조하도록 배달 첨부 파일을 구성합니다.
• 테스트 게재를 실행하여 게재를 준비하는 동안 파일을 사용할 수 있는지 확인합니다.이렇게 하면 Campaign의 원격 URL 다시 인코딩 동작을 방지하고 서버 로컬 첨부 패턴을 따릅니다.**