Campaign Azure Blob SAS Attachment Authentication Failures

配信で、SAS署名されたHTTPS URLによって参照されるAzure Blob Storage ファイルを使用すると、Adobe Campaign配信の準備に失敗する可能性があります。 URLは、ブラウザーまたはcurlで正常に機能する場合がありますが、配信準備中にCampaignが添付ファイルを取得すると失敗します。

説明 description

配信の準備中に、CampaignはAzure Blob Storageから添付ファイルをダウンロードしようとすると、HTTP 403認証エラーが返されます。

HTTP クエリが「サーバーがリクエストの認証に失敗しました」を返しました。
認証ヘッダーの値が正しく形成されていることを確認してください署名を含みます。’ タイプのエラー。

*この問題は、次の場合でも発生する可能性があります。 Azure Blob URLは、web ブラウザーで動作します。

• 同じURLは、正しく引用された場合にcurlで動作します。
• Azure Blob エンドポイントがMID レベルで許可リストに加えるされました。
• この問題は、ステージングと実稼動の両方で再現されます。
• キャンペーンログでSAS URLの形式が正しく表示されます。一部のバリエーションでは、XML エスケープ URLを手動で入力すると、PublicAccessNotPermittedなどのHTTP 409 エラーが発生する場合があります。ビジネス上の影響は、Azureでホストされている添付ファイルに依存するメール配信をブロックし、送信前に配信の準備が失敗することです。## 解決策 resolution**

根本原因

この問題は、CampaignがHTTP リクエストを送信する前にリモート添付ファイル URLを再エンコードしたことが原因で発生します。AzureのSAS URLには、通常、次のようなパーセント エンコードされた文字が署名に含まれています。%2B
%3DCampaignは、添付ファイルの取得操作中にURLを再びエンコードします。 その結果、既にエンコードされた文字は二重エンコードされる可能性があります。元の値：%2B
送信済み値：%252Bその後、Azureは、SAS トークンの生成に使用される署名値とは異なる署名値を受け取ります。 署名が一致しなくなったため、Azureは認証エラーでリクエストを拒否します。&と対&の表現は、Campaignが通常URLを処理する際の根本的な原因ではありません。 XMLのシリアル化は、&などのアンパサンドを表すことができ、Campaignはそれをエスケープ解除できます。 ただし、URLにを手動でおよび入力すると、クエリ区切り記号が正しく解釈されず、予想されるSAS認証エラーではなく409応答が発生する可能性があります。リクエストがAzureに達したが、変更されたSAS許可リストに加えるまたは無効なSAS署名が含まれているため、URL署名で問題が解決しない。また、調査では、リモートのAzure Blob SAS URLを動的に取得された添付ファイルとして使用することが、この配信シナリオの文書化されていない使用ギャップであると判断されました。

解決策

*推奨およびサポートされるアプローチは、配信の準備が整う前に、Azure Blob ファイルをCampaign サーバーにダウンロードすることです。 適切なファイル転送メカニズムまたはAzure Blob APIを呼び出すJavaScript アクティビティを使用して、ワークフロー内のファイルを取得します。

• Campaign サーバーにファイルを保存します。
• ローカルのサーバーサイドのファイルパスを参照するように、配信の添付ファイルを設定します。
• テスト配信を実行して、配信の準備中にファイルが使用可能であることを確認します。これにより、Campaignのリモート URLの再エンコード動作が回避され、サーバーローカルの添付ファイル パターンに従います。**