AEM as a Cloud Service:エラー応答でのリポジトリのメタデータの公開を防ぐ
この記事では、カスタムエラーハンドラー設定がエラー応答でリポジトリメタデータを公開するAdobe Experience Manager as a Cloud Serviceの問題を解決する方法について説明します。 このソリューションでは、エラーページがHTMLとしてレンダリングされるように、エラーハンドラーを更新します。
説明 description
環境
Adobe Experience Manager as a Cloud Service (AEMaaCS)
症状
カスタムエラーハンドラーで処理されたエラー応答は、特に.html拡張機能を指定せずにエラーページがエラーハンドラーに含まれている場合、jcr:primaryType、jcr:createdBy、jcr:createdなどのリポジトリメタデータを公開します。 これは、従来のサーブレット パス (f: /bin/wcm/search/gql.servlet.json)へのリクエストが 404 エラー を返し、カスタム エラーハンドラーJSP (/apps/sling/servlet/errorhandler/default.jspなど)によって処理される場合に発生します。
原因
エラーハンドラーに.html拡張機能のないメンテナンスエラーページが含まれている場合、応答は元のリクエストの拡張機能(.jsonなど)を継承し、リポジトリメタデータが応答本文にシリアル化されます。 機密情報や機密性の高いビジネスデータが公開されることはありませんが、これにより情報開示のリスクが高まります。
解決策 resolution
問題を解決するには、次の手順に従います。
-
プロジェクト コードベースを開き、通常
/apps/sling/servlet/errorhandler/default.jspにあるカスタム エラーハンドラーJSP ファイルを見つけます。 -
メンテナンスエラーページが含まれる行を特定します。 例えば、次のようなものがあります。
<jsp:include page="/content/<your-site>/maintenance/maintenance-error" /> -
各include ステートメントを更新して、
.html拡張機能を明示的に指定します。 次に例を示します。<jsp:include page="/content/<your-site>/maintenance/maintenance-error.html" /> -
変更内容を保存し、標準のデプロイメントプロセスを使用して、更新されたコードをAEM as a Cloud Service環境にデプロイします。
-
影響を受けるエンドポイント (
/bin/wcm/search/gql.servlet.jsonなど)にアクセスして、修正を確認し、エラー応答がリポジトリメタデータを公開しなくなり、HTML エラーページとしてレンダリングされることを確認します。