AEM のコンポーネントとテンプレートは非常に強力なツールキットです。開発者はこれらを使用して、Web サイトビジネスのユーザー、エディターおよび管理者が変化の激しいビジネスニーズに適応しつつ(コンテンツの迅速性)、サイトのレイアウトを統一する(ブランド保護)ための機能を提供します。
特定の Web サイト、または一連の Web サイト(グローバル企業の支社など)の責任者によくある課題は、自身の Web サイトで新しいタイプのコンテンツプレゼンテーションを導入することです。
ここでは、公開済みの他の記事からの抜粋をリストするニュースリストページを Web サイトに追加する必要がある場合について考えます。このページのデザインおよび構造は、Web サイトの他の部分と同じにする必要があります。
このような課題への対応として、以下の方法が推奨されます。
このアプローチによって、Web サイトに寄与しているユーザーおよび管理者が、開発チームに頼ることなく、ビジネスニーズにいかに迅速に対応できるかについて説明します。新しいテンプレートの作成など、代替の方法の場合、通常はコストがかさみ、変更管理プロセスや開発チームの関与が必要になります。これにより、プロセス全体の所用時間とコストが大幅に増大します。
したがって、AEM ベースのシステムの開発者は以下を使用する必要があります。
以下の開発者向けの一般的ルールが、通常のプロジェクトの大多数に該当します。
独自のコンポーネントを作成したり、既存のコンポーネントをカスタマイズしたりするとき、多くの場合は、既存の定義を再利用する方法が最も簡単(かつ安全)です。同じ原則が、エラーハンドラーなど、AEM 内の他の要素にも当てはまります。
これは、既存の定義をコピーしてオーバーレイすることで実行することができます。つまり、/libs
から /apps/<your-project>
に定義をコピーします。この新しい定義は /apps
で、必要に応じて更新できます。
詳しくは、オーバーレイの使用方法を参照してください。
次に例を示します。
これには、コンポーネント定義のオーバーレイが含まれます。
既存のコンポーネントをコピーすることにより、/apps/<website-name>/components/<MyComponent>
に新しいコンポーネントフォルダーを作成してください。
例えば、テキストコンポーネントをカスタマイズするには、次のようにコピーします。
/libs/foundation/components/text
/apps/myProject/components/text
この場合、サーブレットのオーバーレイを含みます。
リポジトリー内で、デフォルトスクリプトを次のようにコピーします。
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
/libs
パス内の設定は一切変更しないでください。
/libs
コンテンツは、インスタンスを次回アップグレードするとき(場合によってはホットフィックスまたは機能パックを適用したとき)に上書きされるからです。
設定およびその他の変更の手順は以下のとおりです。
/libs
内の項目を /apps
にコピー/apps
内での変更JCR クエリは、正しく採用すれば強力なツールとなります。以下の場合に適しています。
コンテンツのフルテキスト検索など、実際のエンドユーザークエリ。
構造化されたコンテンツをリポジトリ全体で見つける必要がある場合。
このような場合、クエリは、コンポーネントアクティベーションやキャッシュ無効化など、絶対に必要な場合にのみ実行してください(ワークフローステップ、コンテンツ変更時にトリガーされるイベントハンドラー、フィルターなどとは対照的)。
JCR クエリは、純粋なレンダリング要求には決して使用しないでください。JCR クエリが不適切な場合の例は以下のとおりです。
コンテンツをレンダリングするためには、JCR クエリを実行する代わりに、コンテンツツリーへのナビゲーションアクセスを使用します。
Query Builder を使用する場合は、JCR クエリを使用します。Query Builder では、内部で JCR クエリが生成されるからです。
セキュリティチェックリストを参照することもお勧めします。
管理セッションではなくユーザーセッションを使用してください。つまり、以下を使用するということです。
slingRequest.getResourceResolver().adaptTo(Session.class);
クロスサイトスクリプティング(XSS)を利用することにより、攻撃者は他のユーザーが表示する Web ページにコードを埋め込むことができます。このセキュリティ脆弱性が悪意のある Web ユーザーに悪用され、アクセス制御が擦り抜けられる可能性があります。
AEM では、ユーザーが提供するコンテンツをすべて出力時にフィルタリングする原則を適用しています。XSS を回避することは、開発時にもテスト時にも第一優先となります。
また、Apache 対応の mod_security などの web アプリケーションファイアウォールを使用すると、デプロイメント環境のセキュリティを高い信頼性で一元的に制御でき、以前は検出されなかったクロスサイトスクリプティング攻撃に対する保護も可能です。
AEM に用意されているサンプルコードは、それ自体ではこのような攻撃に対する保護はおこなわない場合があり、通常は Web アプリケーションファイアウォールによる要求フィルタリングに依存します。
XSS API チートシートには、XSS API を使用して AEM アプリケーションのセキュリティを強化するために知っておく必要のある情報が含まれています。このチートシートは、こちらからダウンロードできます。
XSSAPI チートシート
どのインターネットアプリケーションでも同じですが、機密情報を転送する際は、以下の点を確認してください。
これは、システムに対して機密の情報(設定や管理アクセスなど)とユーザーに対して機密の情報(個人情報の詳細など)の両方に該当します。
エラーページは AEM 用にカスタマイズできます。内部サーバーエラー時にインスタンスが Sling トレースを表示しないようにするために、これをお勧めします。
詳しくは、エラーハンドラーによって表示されるページのカスタマイズを参照してください。
AEM は多数のファイルにアクセスできるので、Java プロセス用に開いているファイルの数を AEM 用に明示的に設定することをお勧めします。
この問題を最小限に留めるために、開発の際は、開かれるすべてのファイルができるだけ早く(ただし合理的な範囲で)、正しく閉じられることを確認する必要があります。