Adobe Experience Manager(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
この場合、サーブレットのオーバーレイを含みます。
リポジトリで、1 つ以上のデフォルトスクリプトをコピーします。
/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 の防止が最も優先されます。
また、Web アプリケーションファイアウォール ( 例: Apache 向け mod_securityを使用すると、デプロイメント環境のセキュリティを一元的に確実に制御し、未検出のクロスサイトスクリプティング攻撃から保護できます。
AEMで提供されるコード例は、それ自体がそのような攻撃から保護されていない場合があり、通常は Web アプリケーションファイアウォールによるリクエストフィルタリングに依存しています。
XSS API チートシートには、XSS API を使用してAEMアプリのセキュリティを高めるために知っておく必要がある情報が含まれています。 こちらからダウンロードできます。
XSSAPI 参照シート。
インターネットアプリケーションに関しては、機密情報を転送する際に必ずお知らせください
これは、システムに機密情報(設定や管理アクセスなど)と、ユーザーに機密情報(個人の詳細など)に当てはまります
エラーページはAEM用にカスタマイズできます。 内部サーバーエラーに対する Sling トレースがインスタンスに表示されないように、これをお勧めします。
詳しくは、 エラーハンドラーによって表示されるエラーページのカスタマイズ を参照してください。
AEMは多くのファイルにアクセスできるので、 Java™プロセス用のファイルを開く をAEM用に明示的に設定します。
この問題を最小限に抑えるために、開発では、(有意義に)可能な限り、開かれたすべてのファイルが正しく閉じられるようにする必要があります。