AEMのコンポーネントとテンプレートは、非常に強力なツールキットを形成します。 開発者は、Web サイトのレイアウトを統一(ブランド保護)したまま、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 用に明示的に設定することをお勧めします。
この問題を最小限に留めるために、開発の際は、開かれるすべてのファイルができるだけ早く(ただし合理的な範囲で)、正しく閉じられることを確認する必要があります。