Dispatcher のバージョンは AEM とは無関係です。以前のバージョンの AEM のドキュメントに組み込まれている Dispatcher のドキュメントへのリンクをたどると、このページにリダイレクトされる可能性があります。
以下の節では、Dispatcher の様々な設定について説明します。
AEM と Dispatcher のすべての要素は、IPv4 と IPv6 の両方のネットワークにインストールできます。IPv4 と IPv6 を参照してください。
デフォルトでは、Dispatcher の設定は dispatcher.any
テキストファイルに格納されますが、インストール時にこのファイルの名前と場所を変更することができます。
設定ファイルには、Dispatcher の動作を制御する一連の単一値または複数値プロパティが含まれます。
/
」)が付きます。{ }
」)を使用して子アイテムを囲みます。設定例を次に示します。
# name of the dispatcher
/name "internet-server"
# each farm configures a set off (loadbalanced) renders
/farms
{
# first farm entry (label is not important, just for your convenience)
/website
{
/clientheaders
{
# List of headers that are passed on
}
/virtualhosts
{
# List of URLs for this Web site
}
/sessionmanagement
{
# settings for user authentification
}
/renders
{
# List of AEM instances that render the documents
}
/filter
{
# List of filters
}
/vanity_urls
{
# List of vanity URLs
}
/cache
{
# Cache configuration
/rules
{
# List of cachable documents
}
/invalidate
{
# List of auto-invalidated documents
}
}
/statistics
{
/categories
{
# The document categories that are used for load balancing estimates
}
}
/stickyConnectionsFor "/myFolder"
/health_check
{
# Page gets contacted when an instance returns a 500
}
/retryDelay "1"
/numberOfRetries "5"
/unavailablePenalty "1"
/failover "1"
}
}
設定に影響を与える他のファイルを含めることができます。
例えば、myFarm.any ファイルを /farms の設定に含めるには、次のコードを使用します。
/farms
{
$include "myFarm.any"
}
アスタリスク (*
) をワイルドカードとして使用し、含めるファイルの範囲を指定します。
例えば、farm_1.any
~ farm_5.any
のファイルにファーム 1 ~ 5 が設定されている場合、これらのファイルを次のように含めることができます。
/farms
{
$include "farm_*.any"
}
値を直接記述する代わりに、dispatcher.any ファイルの単一値プロパティに環境変数を使用できます。環境変数の値を含めるには、${variable_name}
という形式を使用します。
例えば、dispatcher.any ファイルがキャッシュディレクトリと同じディレクトリに配置されている場合は、docroot プロパティに次の値を使用できます。
/docroot "${PWD}/cache"
もう 1 つの例として、AEM パブリッシュインスタンスのホスト名を格納する PUBLISH_IP
という環境変数を作成した場合は、/renders プロパティの次の設定を使用できます。
/renders {
/0001 {
/hostname "${PUBLISH_IP}"
/port "8443"
}
}
Dispatcher インスタンスを識別する一意の名前を指定するには、/name
プロパティを使用します。/name
プロパティは、設定構造の最上位プロパティです。
/farms
プロパティは、1 つまたは複数の Dispatcher の動作セットを定義します。各セットは、異なる Web サイトまたは URL に関連付けられます。/farms
プロパティには、1 つまたは複数のファームを含めることができます。
/farms
プロパティは、設定構造の最上位プロパティです。ファームを定義するには、/farms
プロパティに子プロパティを追加します。Dispatcher インスタンス内でファームを一意に識別するプロパティ名を使用してください。
/farmname
プロパティは複数値で、次のような Dispatcher 動作を定義する他のプロパティを含みます。
値には、任意の英数字(a ~ z、0 ~ 9)を含めることができます。/daycom
および /docsdaycom
という 2 つのファームのスケルトン定義の例を次に示します。
#name of dispatcher
/name "day sites"
#farms section defines a list of farms or sites
/farms
{
/daycom
{
...
}
/docdaycom
{
...
}
}
レンダーファームを複数使用する場合、リストは下から順に評価されます。この順序は、Web サイトの仮想ホストを定義する場合に特に重要です。
各ファームプロパティには、以下の子プロパティを含めることができます。
プロパティ名 | 説明 |
---|---|
/homepage | デフォルトのホームページ(オプション)(IIS のみ) |
/clientheaders | 通過させるクライアント HTTP 要求のヘッダー。 |
/virtualhosts | このファームの仮想ホスト。 |
/sessionmanagement | セッション管理および認証のサポート。 |
/renders | レンダリングされたページを提供するサーバー(一般的には AEM パブリッシュインスタンス)。 |
/filter | Dispatcher がアクセスできる URL を定義します。 |
/vanity_urls | バニティー URL へのアクセスを設定します。 |
/propagateSyndPost | シンジケーション要求の転送のサポート。 |
/cache | キャッシュ動作を設定します。 |
/statistics | ロードバランシング計算用の統計カテゴリの定義。 |
/stickyConnectionsFor | スティッキードキュメントを格納するフォルダー。 |
/health_check | サーバーの可用性を判断するために使用する URL。 |
/retryDelay | 失敗した接続を再試行するまでの遅延。 |
/unavailablePenalty | ロードバランシング計算用の統計に影響を与えるペナルティ。 |
/failover | 元の要求が失敗した場合に異なるレンダーに要求を再送信します。 |
/auth_checker | 権限を区別するキャッシュについては、 セキュリティ保護されたコンテンツのキャッシュ. |
/homepage
パラメーター(IISのみ)は機能しなくなりました。代わりに、 IIS URL 書き換えモジュール.
Apache を使用している場合は mod_rewrite
モジュールを使用する必要があります。詳しくは、Apache Web サイトのドキュメントを参照してください。 mod_rewrite
( 例: Apache 2.4) をクリックします。 を使用する場合 mod_rewrite
の場合は、フラグを使用することをお勧めします 'passthrough|PT' (次のハンドラにパススルー) 書き換えエンジンに uri
内部のフィールド request_rec
構造を filename
フィールドに入力します。
/clientheaders
プロパティでは、Dispatcher がクライアント HTTP 要求からレンダラー(AEM インスタンス)に渡す HTTP ヘッダーのリストを定義します。
デフォルトでは、Dispatcher から AEM インスタンスに標準の HTTP ヘッダーが転送されます。インスタンスによっては、追加のヘッダーを転送したり、特定のヘッダーを削除したりできます。
通過させる一連のヘッダーをカスタマイズした場合は、ヘッダーの完全なリスト(通常はデフォルトで含まれるヘッダーを含む)を指定する必要があります。
例えば、パブリッシュインスタンス向けのページアクティベーション要求を処理する Dispatcher インスタンスには、PATH
セクションに /clientheaders
ヘッダーが必要です。PATH
ヘッダーは、レプリケーションエージェントと Dispatcher 間の通信を可能にします。
次のコードは、/clientheaders
の設定例です。
/clientheaders
{
"CSRF-Token"
"X-Forwarded-Proto"
"referer"
"user-agent"
"authorization"
"from"
"content-type"
"content-length"
"accept-charset"
"accept-encoding"
"accept-language"
"accept"
"host"
"max-forwards"
"proxy-authorization"
"proxy-connection"
"range"
"cookie"
"cq-action"
"cq-handle"
"handle"
"action"
"cqstats"
"depth"
"translate"
"expires"
"date"
"dav"
"ms-author-via"
"if"
"lock-token"
"x-expected-entity-length"
"destination"
"PATH"
}
/virtualhosts
プロパティは、Dispatcher がこのファームに受け入れるすべてのホスト名と URI の組み合わせのリストを定義します。アスタリスク (*
) 文字をワイルドカードとして使用できます。 /virtualhosts
プロパティの値には、次の形式を使用します。
[scheme]host[uri][*]
scheme
:(オプション) https://
または https://.
host
:ホストコンピューターの名前または IP アドレスと、必要な場合はポート番号( https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23)uri
:(オプション)リソースへのパス。次の設定例では、myCompany の .com ドメインと .ch ドメイン、さらに mySubDivision のすべてのドメインに対する要求を処理します。
/virtualhosts
{
"www.myCompany.com"
"www.myCompany.ch"
"www.mySubDivison.*"
}
次の設定は、すべての要求を処理します。
/virtualhosts
{
"*"
}
HTTP 要求または HTTPS 要求を受信すると host,
、uri
および scheme
ヘッダーに最適な仮想ホスト値を探します。Dispatcher は、次の順序で virtualhosts
プロパティの値を評価します。
virtualhosts
プロパティの最上位の値から始め、値のリストの下方向へ進みます。Dispatcher は、以下の方法で最良一致の仮想ホスト値を探します。
host
、scheme
、uri
の 3 つすべてに一致する、最初に見つかった仮想ホストを使用します。virtualhosts
と scheme
の両方に一致する uri
部と scheme
部を持つ uri
値がない場合は、要求の host
に一致する、最初に見つかった仮想ホストを使用します。virtualhosts
値がない場合は、最上位ファームの最上位の仮想ホストを使用します。したがって、デフォルトの仮想ホストは ファイルの最上位ファームの virtualhosts
プロパティの一番上に配置する必要があります。dispatcher.any
次の例は、 dispatcher.any
2 つの Dispatcher ファームを定義し、各ファームは virtualhosts
プロパティ。
/farms
{
/myProducts
{
/virtualhosts
{
"www.mycompany.com"
}
/renders
{
/hostname "server1.myCompany.com"
/port "80"
}
}
/myCompany
{
/virtualhosts
{
"www.mycompany.com/products/*"
}
/renders
{
/hostname "server2.myCompany.com"
/port "80"
}
}
}
以下の表は、この例の場合に、指定された HTTP 要求がどの仮想ホストへと解決されるかを示しています。
リクエスト URL | 解決される仮想ホスト |
---|---|
https://www.mycompany.com/products/gloves.html |
www.mycompany.com/products/ |
https://www.mycompany.com/about.html |
www.mycompany.com |
この機能を有効にするには、/allowAuthorized
セクションで を必ず"0"
/cache
に設定してください。詳しくは、 認証使用時のキャッシュ 」セクションに、 /allowAuthorized 0
認証情報を含むリクエスト: not キャッシュ済み 権限を区別するキャッシュが必要な場合は、 セキュリティ保護されたコンテンツのキャッシュ ページ。
レンダーファームにアクセスするためのセキュアセッションを作成して、このファーム内のページにユーザーがアクセスする際にログインが必要になるようにします。ログイン後、ユーザーはファーム内のページにアクセスできます。閉じられたユーザーグループ(CUG)でのこの機能の使用については、閉じられたユーザーグループの作成を参照してください。また、運用を開始する前に、Dispatcher のセキュリティチェックリストを参照してください。
/sessionmanagement
プロパティは /farms
のサブプロパティです。
Web サイトのセクションによってアクセス要件が異なる場合は、複数のファームを定義する必要があります。
/sessionmanagement には、いくつかのサブパラメーターがあります。
/directory(必須)
セッション情報を格納するディレクトリ。ディレクトリが存在しない場合は自動的に作成されます。
ディレクトリサブパラメーターを設定する場合は、重大な問題が発生する可能性があるので、ルートフォルダー(/directory "/"
)を指定しないでください。セッション情報を格納したフォルダーのパスを必ず指定してください。次に例を示します。
/sessionmanagement
{
/directory "/usr/local/apache/.sessions"
}
/encode(オプション)
セッション情報のエンコード方法。用途 md5
md5 アルゴリズムを使用した暗号化、または hex
を 16 進数エンコーディング用に作成します。 セッションデータを暗号化すると、ファイルシステムにアクセスできるユーザーでも、セッション内容を読み取れなくなります。デフォルトは、md5
です。
/header(オプション)
認証情報を格納する HTTP ヘッダーまたは cookie の名前。ヘッダーに情報を格納する場合は、HTTP:<header-name>
を適用します。cookie に情報を格納する場合は、Cookie:<header-name>
を適用します。値を指定しない場合、HTTP:authorization
が適用されます。
/timeout(オプション)
最後の使用から、セッションのタイムアウトまでの秒数。指定されていない場合 "800"
が使用されているので、ユーザーの最後の要求の少し後、セッションが 13 分以上タイムアウトします。
設定例を次に示します。
/sessionmanagement
{
/directory "/usr/local/apache/.sessions"
/encode "md5"
/header "HTTP:authorization"
/timeout "800"
}
/renders プロパティは、ドキュメントをレンダリングするために Dispatcher が要求を送信する URL を定義します。次の /renders
セクションの例では、レンダリングのために単一の AEM インスタンスを識別しています。
/renders
{
/myRenderer
{
# hostname or IP of the renderer
/hostname "aem.myCompany.com"
# port of the renderer
/port "4503"
# connection timeout in milliseconds, "0" (default) waits indefinitely
/timeout "0"
}
}
次の/renders セクションの例では、Dispatcher と同じコンピューター上で動作するAEMインスタンスを識別しています。
/renders
{
/myRenderer
{
/hostname "127.0.0.1"
/port "4503"
}
}
次の /renders セクションの例では、2 つの AEM インスタンス間で平等にレンダリング要求を分配しています。
/renders
{
/myFirstRenderer
{
/hostname "aem.myCompany.com"
/port "4503"
}
/mySecondRenderer
{
/hostname "127.0.0.1"
/port "4503"
}
}
/timeout
AEM インスタンスにアクセスする接続タイムアウトをミリ秒単位で指定します。デフォルトはです。 "0"
を呼び出し、Dispatcher が無期限に待機します。
/receiveTimeout
応答が返るまでに許容される時間をミリ秒単位で指定します。デフォルトはです。 "600000"
:Dispatcher が 10 分間待機します。 設定 "0"
タイムアウトを完全に消去します。
応答ヘッダーの解析中にタイムアウトに達した場合は、HTTP ステータス 504(Bad Gateway)が返されます。応答本文の読み取り中にタイムアウトに達した場合は、Dispatcher は不完全な応答をクライアントに返しますが、作成されたキャッシュファイルがあれば削除します。
/ipv4
レンダーの IP アドレスを取得するために Dispatcher が getaddrinfo
関数(IPv6 用)を使用するか gethostbyname
関数(IPv4 用)を使用するかを指定します。値 0 を指定すると、getaddrinfo
が使用されます。値: 1
原因 gethostbyname
を使用します。 デフォルト値は 0
です。
この getaddrinfo
関数は、IP アドレスのリストを返します。 Dispatcher は、TCP/IP 接続を確立するまで、そのアドレスのリストを繰り返します。したがって、 ipv4
プロパティは、レンダーホスト名が、 getaddrinfo
関数を使用すると、常に同じ順序の IP アドレスのリストを返します。 この場合、 gethostbyname
関数を使用して、Dispatcher が接続する IP アドレスがランダム化されるようにします。
Amazon Elastic Load Balancing(ELB)は、同じ順序になる可能性がある IP アドレスのリストを使用して、getaddrinfo に応答するサービスです。
/secure
この /secure
プロパティの値は "1"
Dispatcher は HTTPS を使用してAEMインスタンスと通信します。 詳しくは、Using SSL with Dispatcher を参照してください。
/always-resolve
Dispatcher バージョン 4.1.6 では、次のように /always-resolve
プロパティを設定できます。
"1"
これにより、要求ごとにホスト名が解決されます(Dispatcher は IP アドレスをキャッシュしません)。 リクエストごとにホスト情報を取得するために追加の呼び出しが必要となるため、パフォーマンスが多少低下する可能性があります。また、次の例に示すように、このプロパティは動的な IP 解決の問題が発生した場合にも使用できます。
/renders {
/0001 {
/hostname "host-name-here"
/port "4502"
/ipv4 "1"
/always-resolve "1"
}
}
Dispatcher が受け入れる HTTP 要求を指定するには、/filter
セクションを使用します。それ以外のすべての要求は、エラーコード 404(ページが見つかりません)で Web サーバーに返送されます。/filter
セクションが存在しない場合は、すべての要求が受け入れられます。
注意:statfile に対する要求は常に拒否されます。
Dispatcher を使用してアクセスを制限する場合の詳しい考慮事項については、Dispatcher セキュリティチェックリストを参照してください。また、 AEMセキュリティチェックリスト AEMのインストールに関するセキュリティの詳細については、を参照してください。
この /filter
セクションは、HTTP 要求の要求行部分のパターンに従ってコンテンツへのアクセスを拒否または許可する一連のルールで構成されます。 の許可リスト戦略を /filter
セクション:
フィルタールールに変更が生じた場合は常にキャッシュをパージすることをお勧めします。
/filter
の各アイテムには、要求行の特定の要素または要求行全体と照合するタイプとパターンが含まれます。各フィルターには、次のアイテムを含めることができます。
タイプ:/type
は、パターンに一致する要求へのアクセスを許可するか、拒否するかを示します。値は、allow
または deny
のどちらかです。
要求行の要素:/query
、/method
、/url
または /protocol
と、HTTP 要求の要求行の特定部分に応じて要求をフィルタリングするためのパターンを含めます。要求行全体ではなく、要求行の要素に対してフィルタリングすることをお勧めします。
要求行の高度な要素: Dispatcher 4.2.0 から 4 つの新しいフィルター要素を使用できます。/path
、/selectors
、/extension
、/suffix
の各要素です。これらを 1 つ以上含めると、URL パターンをさらに制御することができます。
要求行のうち、これらの各要素が参照する部分について詳しくは、Sling の URL の分解 Wiki ページを参照してください。
/glob
プロパティを使用します。Dispatcher では、glob を使用したフィルタリングは廃止されました。そのため、セキュリティ上の問題につながる可能性があるので、/filter
セクションで glob を使用しないようにしてください。つまり、次の代わりに、
/glob "* *.css *"
以下を使用してください。
/url "*.css"
HTTP/1.1 では リクエストライン 次のように指定します。
Method Request-URI HTTP-Version<CRLF>
この <CRLF>
文字は、キャリッジリターンとそれに続くラインフィードを表します。 次の例は、クライアントが WKND サイトの US-English ページをリクエストしたときに受け取るリクエスト行です。
GET /content/wknd/us/en.html HTTP.1.1<CRLF>
パターンでは、要求行と <CRLF>
文字。
フィルタールールを作成する場合、単純なパターンには二重引用符を使用します(例:"pattern"
)。Dispatcher 4.2.0 以降を使用しており、パターンに正規表現が含まれている場合は、正規表現パターンを一重引用符で囲む必要があります(例:'(pattern1|pattern2)'
)。
4.2.0 より後のバージョンの Dispatcher では、フィルターパターンに POSIX 拡張正規表現を含めることができます。
フィルターが想定どおりにトリガーされない場合は、Dispatcher でトレースログを有効にして、要求を傍受しているフィルターを確認できるようにします。
次のサンプルのフィルターセクションによって、Dispatcher がすべてのファイルに対する要求を拒否します。すべてのファイルへのアクセスを拒否してから、特定の領域へのアクセスを許可してください。
/0001 { /type "deny" /url "*" }
明示的に拒否された領域への要求に対して、「404 error code (page not found)」が返されます。
フィルターを使用して、サンプルの ASP ページの各種要素と、パブリッシュインスタンス内の機密領域へのアクセスを拒否することもできます。次のフィルターは、ASP ページへのアクセスを拒否するものです。
/0002 { /type "deny" /url "*.asp" }
次のサンプルフィルターを使用して、POST メソッドでフォームデータを送信できます。
/filter {
/0001 { /glob "*" /type "deny" }
/0002 { /type "allow" /method "POST" /url "/content/[.]*.form.html" }
}
次の例は、Workflow コンソールへの外部アクセスを拒否するためのフィルターです。
/filter {
/0001 { /glob "*" /type "deny" }
/0002 { /type "allow" /url "/libs/cq/workflow/content/console*" }
}
パブリッシュインスタンスで Web アプリケーションコンテキスト(例えば publish)を使用する場合は、このコンテキストをフィルター定義に追加できます。
/0003 { /type "deny" /url "/publish/libs/cq/workflow/content/console/archive*" }
制限された領域内の単独のページにアクセスする必要がある場合は、そのページへのアクセスを許可できます。例えば、ワークフローコンソール内の「アーカイブ」タブへのアクセスを許可する場合は、次のセクションを追加します。
/0004 { /type "allow" /url "/libs/cq/workflow/content/console/archive*" }
複数のフィルターパターンを 1 つの要求に適用した場合は、最後に適用されたフィルターパターンが有効になります。
このフィルターは、ここで単一引用符の間に定義されている正規表現を使用して、非公開のコンテンツディレクトリで拡張子を有効にします。
/005 { /type "allow" /extension '(css|gif|ico|js|png|swf|jpe?g)' }
それぞれ path、selector および extensions に対するフィルターを使用して、/content
パスからのコンテンツの取得をブロックするルールのサンプルを以下に示します。
/006 {
/type "deny"
/path "/content/*"
/selectors '(feed|rss|pages|languages|blueprint|infinity|tidy|sysview|docview|query|jcr:content|_jcr_content|search|childrenlist|ext|assets|assetsearch|[0-9-]+)'
/extension '(json|xml|html|feed))'
}
Dispatcher を設定する際は、できる限り外部アクセスを制限してください。次の例では、外部の訪問者に最小限のアクセス権を付与します。
/content
デザインなどのその他のコンテンツおよびクライアントライブラリ。次のようなものがあります。
/etc/designs/default*
/etc/designs/mydesign*
フィルターを作成したら、ページアクセスをテストして、AEM インスタンスがセキュアであることを確認します。
以下 /filter
セクション dispatcher.any
ファイルを Dispatcher 設定ファイル。
このサンプルは、Dispatcher に付属するデフォルトの設定ファイルをベースとしており、実稼動環境での使用例の役割を果たすことを目的としています。プレフィックスが付いた項目 #
を非アクティブ化(コメントアウト)した場合、次のいずれかをアクティブ化する ( #
を参照してください )。セキュリティ上の影響を受ける可能性があります。
すべてに対するアクセスを拒否してから、特定の(限られた)要素へのアクセスを許可してください。
/filter
{
# Deny everything first and then allow specific entries
/0001 { /type "deny" /url "*" }
# Open consoles
# /0011 { /type "allow" /url "/admin/*" } # allow servlet engine admin
# /0012 { /type "allow" /url "/crx/*" } # allow content repository
# /0013 { /type "allow" /url "/system/*" } # allow OSGi console
# Allow non-public content directories
# /0021 { /type "allow" /url "/apps/*" } # allow apps access
# /0022 { /type "allow" /url "/bin/*" }
/0023 { /type "allow" /url "/content*" } # disable this rule to allow mapped content only
# /0024 { /type "allow" /url "/libs/*" }
# /0025 { /type "deny" /url "/libs/shindig/proxy*" } # if you enable /libs close access to proxy
# /0026 { /type "allow" /url "/home/*" }
# /0027 { /type "allow" /url "/tmp/*" }
# /0028 { /type "allow" /url "/var/*" }
# Enable extensions in non-public content directories, using a regular expression
/0041
{
/type "allow"
/extension '(css|gif|ico|js|png|swf|jpe?g)'
}
# Enable features
/0062 { /type "allow" /url "/libs/cq/personalization/*" } # enable personalization
# Deny content grabbing, on all accessible pages, using regular expressions
/0081
{
/type "deny"
/selectors '((sys|doc)view|query|[0-9-]+)'
/extension '(json|xml)'
}
# Deny content grabbing for /content and its subtree
/0082
{
/type "deny"
/path "/content/*"
/selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'
/extension '(json|xml|html)'
}
# /0087 { /type "allow" /method "GET" /extension 'json' "*.1.json" } # allow one-level json requests
}
Apache と共に使用する場合は、Dispatcher モジュールの DispatcherUseProcessedURL プロパティに応じてフィルター URL パターンをデザインしてください(「Apache Web サーバー - Dispatcher 用の Apache Web サーバーの設定」を参照。)
アクセスを拡張する場合は、以下の推奨事項について検討します。
CQ バージョン 5.4 以前を使用している場合は、/admin
への外部アクセスを常に完全に**無効にしてください。
/libs
内にあるファイルへのアクセスを許可する場合は、注意が必要です。アクセスは、個別に許可する必要があります。
レプリケーション複製の設定が表示されないよう、この設定へのアクセスを拒否してください。
/etc/replication.xml*
/etc/replication.infinity.json*
Google Gadgets のリバースプロキシへのアクセスを拒否します。
/libs/opensocial/proxy*
インストールによっては、/apps
、/libs
またはその他の場所(使用可能にする必要があります)の下に、追加のリソースが存在する場合があります。外部からアクセスされるリソースを判別するための方法として、access.log
ファイルを使用することができます。
コンソールおよびディレクトリへのアクセスによって、実稼動環境でセキュリティのリスクが発生する可能性があります。このようなアクセスに関する正当な理由が明確でない場合は、これらのエントリを非アクティブ化(コメントアウト)のままにしておいてください。
次の場合、 パブリッシュ環境でのレポートの使用 へのアクセスを拒否するように Dispatcher を設定する必要があります。 /etc/reports
外部の訪問者用。
Dispatcher バージョン 4.1.5 以降では、/filter
セクションを使用してクエリ文字列を制約します。allow
フィルター要素を使用して、クエリ文字列を明示的に許可し、一般的な許可を除外することを強くお勧めします。
1 つのエントリに、 glob
または組み合わせ method
, url
, query
、および version
ですが、両方ではありません。 以下の例では、a=*
ノードに解決される URL に対してクエリ文字列 /etc
を許可し、その他すべてのクエリ文字列を拒否しています。
/filter {
/0001 { /type "deny" /method "POST" /url "/etc/*" }
/0002 { /type "allow" /method "GET" /url "/etc/*" /query "a=*" }
}
ルールに /query
が含まれる場合は、クエリ文字列を含む要求だけでなく、指定されたクエリパターンも照合します。
上記の例で、クエリ文字列を持たない /etc
への要求も許可する場合は、以下のルールが必要になります。
/filter {
>/0001 { /type "deny" /method “*" /url "/path/*" }
>/0002 { /type "allow" /method "GET" /url "/path/*" }
>/0003 { /type “deny" /method "GET" /url "/path/*" /query "*" }
>/0004 { /type "allow" /method "GET" /url "/path/*" /query "a=*" }
}
Dispatcher のフィルターは、AEM パブリッシュインスタンス上の以下のページおよびスクリプトへのアクセスをブロックする必要があります。Web ブラウザーを使用して、サイト訪問者として以下のページを開こうと試み、コード 404 が返されることを確認してください。それ以外の結果が得られた場合は、フィルターを調整してください。
次の場合は、通常のページレンダリングが表示されます。 /content/add_valid_page.html?debug=layout
.
/admin
/system/console
/dav/crx.default
/crx
/bin/crxde/logs
/jcr:system/jcr:versionStorage.json
/_jcr_system/_jcr_versionStorage.json
/libs/wcm/core/content/siteadmin.html
/libs/collab/core/content/admin.html
/libs/cq/ui/content/dumplibs.html
/var/linkchecker.html
/etc/linkchecker.html
/home/users/a/admin/profile.json
/home/users/a/admin/profile.xml
/libs/cq/core/content/login.json
/content/../libs/foundation/components/text/text.jsp
/content/.{.}/libs/foundation/components/text/text.jsp
/apps/sling/config/org.apache.felix.webconsole.internal.servlet.OsgiManager.config/jcr%3acontent/jcr%3adata
/libs/foundation/components/primary/cq/workflow/components/participants/json.GET.servlet
/content.pages.json
/content.languages.json
/content.blueprint.json
/content.-1.json
/content.10.json
/content.infinity.json
/content.tidy.json
/content.tidy.-1.blubber.json
/content/dam.tidy.-100.json
/content/content/geometrixx.sitemap.txt
/content/add_valid_page.query.json?statement=//*
/content/add_valid_page.qu%65ry.js%6Fn?statement=//*
/content/add_valid_page.query.json?statement=//*[@transportPassword]/(@transportPassword%20|%20@transportUri%20|%20@transportUser)
/content/add_valid_path_to_a_page/_jcr_content.json
/content/add_valid_path_to_a_page/jcr:content.json
/content/add_valid_path_to_a_page/_jcr_content.feed
/content/add_valid_path_to_a_page/jcr:content.feed
/content/add_valid_path_to_a_page/pagename._jcr_content.feed
/content/add_valid_path_to_a_page/pagename.jcr:content.feed
/content/add_valid_path_to_a_page/pagename.docview.xml
/content/add_valid_path_to_a_page/pagename.docview.json
/content/add_valid_path_to_a_page/pagename.sysview.xml
/etc.xml
/content.feed.xml
/content.rss.xml
/content.feed.html
/content/add_valid_page.html?debug=layout
/projects
/tagging
/etc/replication.html
/etc/cloudservices.html
/welcome
端末またはコマンドプロンプトで次のコマンドを発行して、匿名での書き込みアクセスが可能かどうかを判断します。ノードにはデータを書き込みできません。
curl -X POST "https://anonymous:anonymous@hostname:port/content/usergenerated/mytestnode"
ターミナルまたはコマンドプロンプトで次のコマンドを発行して、Dispatcher キャッシュの無効化を試み、コード 403 応答を受け取ることを確認します。
curl -H "CQ-Handle: /content" -H "CQ-Path: /content" https://yourhostname/dispatcher/invalidate.cache
AEMページ用に設定されたバニティー URL へのアクセスを有効にするように Dispatcher を設定します。
バニティー URL へのアクセスが有効になると、レンダーインスタンス上で実行されているサービスを Dispatcher が定期的に呼び出して、バニティー URL のリストを取得します。Dispatcher がこのリストをローカルファイルに保存します。ページの要求が /filter
セクションのフィルターによって拒否されると、Dispatcher はバニティー URL のリストを調べます。拒否された URL がリストにある場合、Dispatcher はバニティー URL へのアクセスを許可します。
バニティー URL へのアクセスを有効にするには、以下の例のような /vanity_urls
セクションを /farms
セクションに追加します。
/vanity_urls {
/url "/libs/granite/dispatcher/content/vanityUrls.html"
/file "/tmp/vanity_urls"
/delay 300
}
/vanity_urls
セクションには、以下のプロパティが含まれます。
/url
:レンダーインスタンス上で実行されているバニティー URL サービスへのパス。このプロパティの値は、"/libs/granite/dispatcher/content/vanityUrls.html"
である必要があります。
/file
:Dispatcher がバニティー URL のリストを保存するローカルファイルへのパス。Dispatcher がこのファイルに対する書き込みアクセス権を持っていることを確認してください。
/delay
:バニティー URL サービスの呼び出し間隔(秒単位)。
レンダーがAEMのインスタンスである場合は、 ソフトウェア配布からの VanityURLS-Components パッケージ バニティー URL サービスを有効にする。 ( ソフトウェア配布 詳細はこちら )。
バニティー URL へのアクセスを有効にするには、以下の手順を実行します。
com.adobe.granite.dispatcher.vanityurl.content
パッケージをパブリッシュインスタンス上に作成します(上記の注意を参照)。/filter
設定がその URL を拒否していることを確認します。必要に応じて、この URL を拒否するフィルターを追加します。/farms
の下に /vanity_urls
セクションを追加します。シンジケーション要求は、通常、Dispatcher のみを対象としているので、デフォルトではレンダラー(AEM インスタンスなど)に送信されません。
必要に応じて、 /propagateSyndPost
プロパティを "1"
シンジケーション要求を Dispatcher に転送する。 設定する場合、フィルターセクションで POST 要求が拒否されていないことを確認する必要があります。
/cache
セクションは、Dispatcher によるドキュメントのキャッシュ方法を制御します。次のいくつかのサブプロパティを設定して、キャッシュ戦略を実装します。
/docroot
/statfile
/serveStaleOnError
/allowAuthorized
/rules
/statfileslevel
/invalidate
/invalidateHandler
/allowedClients
/ignoreUrlParams
/headers
/mode
/gracePeriod
/enableTTL
キャッシュセクションの例を次に示します。
/cache
{
/docroot "/opt/dispatcher/cache"
/statfile "/tmp/dispatcher-website.stat"
/allowAuthorized "0"
/rules
{
# List of files that are cached
}
/invalidate
{
# List of files that are auto-invalidated
}
}
権限を区別するキャッシュについては、セキュリティ保護されたコンテンツのキャッシュを参照してください。
/docroot
プロパティは、キャッシュされたファイルを保存するディレクトリを識別します。
Dispatcher と Web サーバーが同じファイルを処理できるよう、この値は Web サーバーのドキュメントルートとまったく同じパスの必要があります。
Dispatcher のキャッシュファイルが使用されると、Web サーバーは適切なステータスコードを配信します。そのため、キャッシュファイルを見つけられることが重要になります。
複数のファームを使用する場合は、ファームごとに異なるドキュメントルートを使用する必要があります。
/statfile
プロパティは、statfile として使用するファイルを識別します。Dispatcher は、このファイルを使用して、最も新しいコンテンツ更新時刻を登録します。statfile には、Web サーバー上の任意のファイルを指定できます。
statfile にはコンテンツがありません。コンテンツが更新されると、Dispatcher がタイムスタンプを更新します。デフォルトの statfile の名前はです。 .stat
とは docroot に保存されます。 Dispatcher は、statfile へのアクセスをブロックします。
If /statfileslevel
が設定されている場合、Dispatcher は /statfile
プロパティと使用 .stat
名前として。
/serveStaleOnError
プロパティは、レンダーサーバーがエラーを返した場合に Dispatcher が無効になったドキュメントを返すかどうかを制御します。デフォルトでは、statfile にアクセスし、キャッシュされたコンテンツが無効になると、Dispatcher は次回要求時にキャッシュされたコンテンツを削除します。
If /serveStaleOnError
が "1"
に設定すると、レンダーサーバーが成功応答を返さない限り、Dispatcher は無効になったコンテンツをキャッシュから削除しません。 AEM からの応答 5xx または接続タイムアウトによって、Dispatcher は期限切れのコンテンツを返し、HTTP ステータス 111(再検証失敗)で応答します。
/allowAuthorized
プロパティは、以下のいずれかの認証情報を含む要求をキャッシュするかどうかを制御します。
authorization
ヘッダーauthorization
login-token
デフォルトでは、この認証情報を含む要求はキャッシュされません。キャッシュされたドキュメントをクライアントに返す場合、認証は実行されないからです。この設定によって、Dispatcher は、必要な権限を持たないユーザーにキャッシュされたドキュメントを返さなくなります。
ただし、認証済みドキュメントのキャッシュが要件によって許可されている場合は、 /allowAuthorized
を 1 に変更します。
/allowAuthorized "1"
セッション管理(/sessionmanagement
プロパティを使用)を有効にするには、/allowAuthorized
プロパティを "0"
に設定する必要があります。
/rules
プロパティは、ドキュメントパスに応じてキャッシュされるドキュメントを制御します。/rules
プロパティにかかわらず、Dispatcher は以下の状況にあるドキュメントをキャッシュしません。
要求 URI に疑問符 (?
) をクリックします。
ファイル拡張子が不明の場合。
認証ヘッダー(設定可)が設定されている場合。。
AEM インスタンスが以下のヘッダーで応答する場合。
no-cache
no-store
must-revalidate
(HTTP ヘッダー用の)GET または HEAD メソッドは、Dispatcher によってキャッシュ可能です。応答ヘッダーのキャッシュについて詳しくは、HTTP 応答ヘッダーのキャッシュセクションを参照してください。
各項目の /rules
プロパティには、 glob
パターンとタイプ:
glob
パターンは、ドキュメントのパスを照合するために使用されます。glob
パターン。 値は、allow(ドキュメントをキャッシュする)または deny(ドキュメントを常にレンダリングする)のどちらかです。以上のルールで除外されるもの以外にも動的ページがない場合、Dispatcher ですべてのドキュメントをキャッシュできます。この場合、ルールセクションは次のようになります。
/rules
{
/0000 { /glob "*" /type "allow" }
}
glob プロパティについて詳しくは、glob プロパティのパターンのデザインを参照してください。
ページ内に動的なセクション(ニュースアプリケーションなど)や、非公開のユーザーグループで使用するセクションがある場合は、以下のように例外を定義できます。
キャッシュされたページでユーザー権限をチェックできないので、非公開のユーザーグループはキャッシュできません。
/rules
{
/0000 { /glob "*" /type "allow" }
/0001 { /glob "/en/news/*" /type "deny" }
/0002 { /glob "*/private/*" /type "deny" }
}
圧縮
Apache Web サーバーでは、キャッシュされたドキュメントを圧縮することができます。クライアントから要求された場合は、Apache から圧縮形式のドキュメントを返すことができます。例えば、Apache モジュールの mod_deflate
を有効にすることで、圧縮は自動的に行われます。
AddOutputFilterByType DEFLATE text/plain
このモジュールは Apache 2.x にデフォルトでインストールされています。
/statfileslevel
プロパティを使用して、キャッシュされたファイルをパスに応じて選択的に無効化します。
Dispatcher は、ドキュメントルートフォルダーから指定したレベルまでの各フォルダーに .stat
ファイルを作成します。ドキュメントルートはレベル 0 です。
.stat
ファイルが更新されると、ファイルは無効化されます。.stat
ファイルの最終変更日と、キャッシュされたドキュメントの最終変更日を比較します。.stat
ファイルのほうが新しい場合は、ドキュメントを再取得します。
特定のレベルにあるファイルが無効化されると、docroot から無効化されたファイルのレベルまたは設定された statsfilevel
まで(いずれか小さい方)のすべての .stat
ファイルが touch されます。
statfileslevel
プロパティを 6 に設定し、レベル 5 でファイルが無効化されると、docroot から 5 までのすべての .stat
ファイルが touch されます。この例では、ファイルがレベル 7 で無効化されると、docroot から 6 までのすべての .stat
ファイルが touch されます(/statfileslevel = "6"
なので)。リソースのみ 道に沿って 無効化されたファイルに影響を与えます。 次の例を考えて見ましょう。Web サイトで /content/myWebsite/xx/.
構造を使用していて、statfileslevel
を 3 に設定している場合、.stat
ファイルは次のように作成されます。
docroot
/content
/content/myWebsite
/content/myWebsite/*xx*
ファイル /content/myWebsite/xx
が無効化された場合、docroot から /content/myWebsite/xx
までのすべての .stat
ファイルが touch されます。これは、/content/myWebsite/xx
のみに当てはまり、/content/myWebsite/yy
や /content/anotherWebSite
などには当てはまりません。
無効化は、追加のヘッダー CQ-Action-Scope:ResourceOnly
を送信することで防止できます。これを使用することで、キャッシュの他の部分を無効化せずに、特定のリソースをフラッシュできます。詳しくは、 このページ および 手動での Dispatcher キャッシュの無効化 を参照してください。
注意:/statfileslevel
プロパティの値を指定した場合、/statfile
プロパティは無視されます。
/invalidate
プロパティは、コンテンツが更新されたときに自動的に無効化されるドキュメントを定義します。
自動無効化を使用する場合、Dispatcher はキャッシュされたファイルをコンテンツの更新後に削除しませんが、次回要求されたときにその有効性を確認します。自動無効化されない、キャッシュ内のドキュメントは、コンテンツの更新によって明示的に削除されるまでキャッシュに残ります。
自動無効化は通常、HTML ページに対して使用されます。多くの場合、HTML ページには他のページへのリンクが含まれるので、コンテンツの更新がページに影響を与えるかどうかを判断することが困難です。コンテンツの更新時にすべての関連ページが無効化されるようにするには、すべての HTML ページを自動的に無効化します。以下の設定は、すべての HTML ページを無効化します。
/invalidate
{
/0000 { /glob "*" /type "deny" }
/0001 { /glob "*.html" /type "allow" }
}
glob プロパティについて詳しくは、glob プロパティのパターンのデザインを参照してください。
この設定により、次のアクティビティが発生します。 /content/wknd/us/en
有効化済み:
/content/wknd/us
フォルダー。/content/wknd/us/en./_jcr_content
フォルダーが削除されました。/invalidate
設定は直ちには削除されません。 これらのファイルは、次回の要求が発生すると削除されます。この例では /content/wknd.html
が削除されていない場合、 /content/wknd.html
がリクエストされました。自動生成した PDF や ZIP ファイルをダウンロード用に提供する場合は、これらのファイルも自動的に無効化する必要があります。この場合の設定例を次に示します。
/invalidate
{
/0000 { /glob "*" /type "deny" }
/0001 { /glob "*.html" /type "allow" }
/0002 { /glob "*.zip" /type "allow" }
/0003 { /glob "*.pdf" /type "allow" }
}
AEMとAdobe Analyticsの統合により、 analytics.sitecatalyst.js
ファイルを Web サイト内に配置する必要があります。 例 dispatcher.any
Dispatcher で提供されるファイルには、このファイルに対して次の無効化ルールが含まれます。
{
/glob "*/analytics.sitecatalyst.js" /type "allow"
}
この /invalidateHandler
プロパティを使用すると、Dispatcher が受信した無効化要求ごとに呼び出されるスクリプトを定義できます。
このスクリプトは、以下の引数と共に呼び出されます。
CQ-Action-Scope: ResourceOnly
が送信された場合は、 AEMからのキャッシュされたページの無効化 (詳細)このスクリプトは、他のアプリケーションに固有のキャッシュの無効化など、多種多様なユースケースを扱ったり、外部化されたページの URL とドキュメントルート内のその場所がコンテンツパスと一致しないケースを扱ったりするのに利用できます。
以下のサンプルスクリプトは、各無効化要求をファイルに記録します。
/invalidateHandler "/opt/dispatcher/scripts/invalidate.sh"
#!/bin/bash
printf "%-15s: %s %s" $1 $2 $3>> /opt/dispatcher/logs/invalidate.log
この /allowedClients
プロパティは、キャッシュのフラッシュを許可する特定のクライアントを定義します。 このグロビングパターンが、IP と照合されます。
以下の例の内容は次のとおりです。
/allowedClients
{
/0001 { /glob "*.*.*.*" /type "deny" }
/0002 { /glob "127.0.0.1" /type "allow" }
}
glob プロパティについて詳しくは、glob プロパティのパターンのデザインを参照してください。
次の項目を定義することをお勧めします。 /allowedClients
.
定義しない場合は、任意のクライアントからキャッシュ消去を呼び出せますが、繰り返しおこなうとサイトのパフォーマンスに深刻な影響を及ぼす場合があります。
ignoreUrlParams
セクションでは、ページをキャッシュするかキャッシュから提供するかを判断するときにどの URL パラメーターを無視するかを定義します。
あるページに対してパラメーターを無視する場合は、そのページが初めて要求されたときにページがキャッシュされます。そのページに対する以降の要求には、要求内のパラメーターの値にかかわらず、キャッシュされたページが返されます。
この場合、 ignoreUrlParams
設定を適切に許可リスト指定した。 そのため、すべてのクエリパラメーターは無視され、既知のクエリパラメーターまたは予期されたクエリパラメーターのみが無視されます(「拒否」)。 その他の詳細と例については、 このページ.
無視するパラメーターを指定するには、ignoreUrlParams
プロパティに glob ルールを追加します。
glob プロパティを設定する際は、クエリパラメーター名と一致する必要があることに注意してください。 例えば、次の URL の「p1」パラメーターを無視する場合は、 http://example.com/path/test.html?p1=test&p2=v2
を指定した場合、glob プロパティは次のようになります。
/0002 { /glob "p1" /type "allow" }
次の例では、Dispatcher が、 nocache
パラメーター。 したがって、 nocache
パラメーターは、Dispatcher によってキャッシュされません。
/ignoreUrlParams
{
# allow-the-url-parameter-nocache-to-bypass-dispatcher-on-every-request
/0001 { /glob "nocache" /type "deny" }
# all-other-url-parameters-are-ignored-by-dispatcher-and-requests-are-cached
/0002 { /glob "*" /type "allow" }
}
のコンテキストでは、 ignoreUrlParams
上記の設定例では、次の HTTP 要求によって、ページがキャッシュされます。これは、 willbecached
パラメーターは無視されます:
GET /mypage.html?willbecached=true
のコンテキストでは、 ignoreUrlParams
設定例では、次の HTTP 要求によってページが not キャッシュされるのは nocache
パラメーターは無視されません:
GET /mypage.html?nocache=true
GET /mypage.html?nocache=true&willbecached=true
glob プロパティについて詳しくは、glob プロパティのパターンのデザインを参照してください。
この機能は、Dispatcher のバージョン 4.1.11 で利用できます。
/headers
プロパティを使用して、Dispatcher がキャッシュする HTTP ヘッダータイプを定義できます。キャッシュされていないリソースへの最初のリクエストでは、設定済みの値(以下の設定サンプルを参照)のいずれかに一致するすべてのヘッダーが、キャッシュファイルの隣の別ファイルに格納されます。キャッシュされたリソースに対する後続のリクエストでは、保存されたヘッダーが応答に追加されます。
以下に、デフォルト設定のサンプルを示します。
/cache {
...
/headers {
"Cache-Control"
"Content-Disposition"
"Content-Type"
"Expires"
"Last-Modified"
"X-Content-Type-Options"
"Last-Modified"
}
}
また、ファイルのグロビング文字は使用できないことに注意してください。 詳しくは、glob プロパティのパターンのデザインを参照してください。
Dispatcher を使用して AEMから ETag 応答ヘッダーを保存および配信する必要がある場合は、以下の手順を実行します。
/cache/headers
セクションにヘッダー名を追加します。FileETag none
mode
プロパティは、新しいディレクトリおよびキャッシュ内のファイルに適用されるファイル権限を指定します。この設定は、呼び出し元のプロセスの umask
によって制限されます。これは、次の値のうち 1 つまたは複数の合計から構成される 8 進数です。
0400
所有者による読み取りを許可します。0200
所有者による書き込みを許可します。0100
所有者によるディレクトリ内の検索を許可します。0040
グループメンバーによる読み取りを許可します。0020
グループメンバーによる書き込みを許可します。0010
グループメンバーによるディレクトリ内の検索を許可します。0004
その他のユーザーによる読み取りを許可します。0002
その他のユーザーによる書き込みを許可します。0001
その他のユーザーによるディレクトリ内の検索を許可します。デフォルト値は 0755
これにより、所有者は読み取り、書き込みまたは検索を行い、グループとその他のユーザーは読み取りまたは検索を行うことができます。
デフォルトの /invalidate
のプロパティでは、アクティベーションごとに、すべての .html
ファイルが無効化されます(パスが /invalidate
セクションに一致する場合)。トラフィック量が多い Web サイトでは、複数回のアクティベーションによってバックエンドの CPU 負荷が増加します。このようなシナリオでは、Web サイトをレスポンシブに維持するために、「スロットル」 .stat
ファイルを使用することをお勧めします。これを行うには、/gracePeriod
プロパティを使用します。
/gracePeriod
プロパティは、自動的に無効化された古いリソースを、前回のアクティベーション後にキャッシュから引き続き使用できる秒数を定義します。このプロパティは、アクティベートのバッチによってキャッシュ全体が繰り返し無効化されるような設定で使用できます。推奨される値は 2 秒です。
詳細については、上記の /invalidate
および /statfileslevel
セクションも参照してください。
1 に設定した場合 (/enableTTL "1"
)、 /enableTTL
プロパティは、バックエンドからの応答ヘッダーを評価し、ヘッダーに Cache-Control
max-age または Expires
日付:キャッシュファイルの横に、有効期限と同じ変更時刻を持つ予備の空のファイルが作成されます。 変更時刻以降にキャッシュされたファイルが要求されると、自動的にバックエンドから再要求されます。
TTL ベースのキャッシュはヘッダーキャッシュのスーパーセットであり、そのように /headers
プロパティも適切に設定される必要があります。
この機能は、バージョンで使用できます 4.1.11 または Dispatcher の後半で呼び出します。
/statistics
セクションは、Dispatcher が各レンダーの応答性のスコアを付けるファイルのカテゴリを定義します。Dispatcher は、このスコアを使用して、要求を送信するレンダーを決定します。
作成したカテゴリごとに glob パターンを定義します。Dispatcher は、要求されたコンテンツの URI とこれらのパターンを比較して、要求されたコンテンツのカテゴリを決定します。
Dispatcher は、最大 8 個の統計カテゴリをサポートします。9 個以上のカテゴリを定義した場合は、最初の 8 個のカテゴリのみが使用されます。
レンダーの選択
レンダリングされたページを要求するたびに、Dispatcher は以下のアルゴリズムを使用してレンダーを選択します。
要求の renderid
cookie にレンダー名が格納されている場合、Dispatcher はそのレンダーを使用します。
要求に renderid
cookie が含まれていない場合、Dispatcher はレンダー統計を比較します。
まだレンダーが選択されていない場合は、リストの先頭のレンダーを使用します。
レンダーのカテゴリのスコアは、以前の応答時間と Dispatcher が以前試みた接続の失敗および成功に基づきます。試行ごとに、要求された URI のカテゴリのスコアが更新されます。
ロードバランシングを使用しない場合は、このセクションを省略できます。
レンダーを選択するための統計を保持するドキュメントのタイプごとにカテゴリを定義します。この /statistics
セクションには /categories
」セクションに入力します。 カテゴリを定義するには、 /categories
セクションに次の形式が含まれる場合。
/name { /glob "pattern"}
カテゴリ name
は、ファームに対して一意である必要があります。pattern
については、glob プロパティのパターンのデザインのセクションで説明します。
URI のカテゴリを判断するために、Dispatcher は一致が見つかるまで URI と各カテゴリのパターンを比較します。Dispatcher は、リストの先頭のカテゴリから始め、順序に従って比較を続けます。したがって、より具体的なパターンを持つカテゴリを先頭に配置してください。
例えば、Dispatcher がデフォルト dispatcher.any
ファイルは、カテゴリと othersHTMLを定義します。 HTML カテゴリのほうが具体的なので、先頭に配置されています。
/statistics
{
/categories
{
/html { /glob "*.html" }
/others { /glob "*" }
}
}
以下の例には、検索ページ用のカテゴリも含まれています。
/statistics
{
/categories
{
/search { /glob "*search.html" }
/html { /glob "*.html" }
/others { /glob "*" }
}
}
/unavailablePenalty
プロパティは、レンダーへの接続が失敗した場合にレンダー統計に適用される時間(0.1 秒単位)を設定します。Dispatcher は、要求された URI に一致する統計カテゴリにこの時間を追加します。
例えば、AEM が実行されていない(したがってリッスンしていない)か、ネットワーク関連の問題が発生したので、指定したホスト名およびポートへの TCP/IP 接続を確立できない場合にペナルティが適用されます。
/unavailablePenalty
プロパティは、/farm
セクション(/statistics
セクションの兄弟)の直接の子です。
指定しない場合 /unavailablePenalty
プロパティが存在する場合、値は "1"
が使用されます。
/unavailablePenalty "1"
/stickyConnectionsFor
プロパティは、スティッキードキュメントを格納する 1 つのフォルダーを定義します。このフォルダーには、URL を使用してアクセスします。Dispatcher によって、このフォルダーにある、単一のユーザーからのすべての要求が同一のレンダーインスタンスに送信されます。スティッキー接続は、すべてのドキュメントに必ず一貫したセッションデータが存在することを保証します。このメカニズムは、renderid
cookie を利用しています。
次の例は、/products フォルダーへのスティッキー接続を定義しています。
/stickyConnectionsFor "/products"
ページが複数のコンテンツノードのコンテンツで組み立てられている場合は、コンテンツへのパスをリストする /paths
プロパティを含めます。例えば、/content/image
、/content/video
および /var/files/pdfs
のコンテンツを含むページがあるとします。以下の設定を使用すると、ページ上のすべてのコンテンツに対してスティッキー接続が有効になります。
/stickyConnections {
/paths {
"/content/image"
"/content/video"
"/var/files/pdfs"
}
}
スティッキー接続が有効になっている場合、dispatcher モジュールは renderid
cookie を設定します。この cookie には httponly
フラグがないため、セキュリティを強化するためにこのフラグを追加する必要があります。これをおこなうには、httpOnly
設定ファイルの /stickyConnections
ノードで dispatcher.any
プロパティを設定します。プロパティの値 ( 0
または 1
) は、 renderid
cookie に HttpOnly
属性が追加されました。 デフォルト値は 0
:属性は追加されないことを意味します。
詳しくは、 httponly
フラグ、読み取り このページ.
スティッキー接続が有効になっている場合、dispatcher モジュールは renderid
cookie を設定します。この cookie には secure
フラグがないため、セキュリティを強化するためにこのフラグを追加する必要があります。これをおこなうには、secure
設定ファイルの /stickyConnections
ノードで dispatcher.any
プロパティを設定します。プロパティの値 ( 0
または 1
) は、 renderid
cookie に secure
属性が追加されました。 デフォルト値は 0
は、属性が追加されることを意味します。 if 受信リクエストはセキュリティで保護されています。 値が 1
を指定した場合、受信リクエストがセキュアかどうかに関係なく、secure フラグが追加されます。
レンダーサーバーが 500 エラー、すなわち使用不可を返した場合の Dispatcher の動作を設定します。
/health_check
プロパティを使用して、ステータスコード 500 が発生したときに確認する URL を指定します。このページもステータスコード 500 を返す場合、インスタンスは使用不可能と見なされ、再試行の前に設定可能なタイムペナルティ(/unavailablePenalty
)がレンダーに適用されます。
/health_check
{
# Page gets contacted when an instance returns a 500
/url "/health_check.html"
}
この /retryDelay
プロパティは、Dispatcher が待機する、ファームレンダーへの接続試行周期(秒)を設定します。 周期ごとに、Dispatcher が 1 つのレンダーに対して接続を試行する最大回数は、ファーム内のレンダーの数です。
/retryDelay
が明示的に定義されていない場合、Dispatcher は値 "1"
を使用します。デフォルト値は、ほとんどのケースに適しています。
/retryDelay "1"
/numberOfRetries
プロパティは、Dispatcher がレンダーに対して実行する。接続試行周期の最大回数を設定します。この再試行回数内で Dispatcher がレンダーに接続できなかった場合、Dispatcher は失敗応答を返します。
周期ごとに、Dispatcher が 1 つのレンダーに対して接続を試行する最大回数は、ファーム内のレンダーの数です。したがって、Dispatcher が接続を試みる最大回数は(/numberOfRetries
)x(レンダー数)になります。
明示的な定義がない場合、5
がデフォルトの値として使用されます。
/numberOfRetries "5"
Dispatcher ファーム上でフェイルオーバーメカニズムを有効にして、元の要求の失敗時に異なるレンダーに要求を再送信します。フェイルオーバーを有効にすると、Dispatcher は以下の動作をおこないます。
health_check
プロパティに設定されているページへの要求を送信します。
フェイルオーバーを有効にするには、次の行をファーム(または Web サイト)に追加します。
/failover "1"
本文を含む HTTP 要求を再試行するには、Dispatcher が Expect: 100-continue
要求ヘッダーをレンダーに送信してから、実際のコンテンツをスプールします。すると、CQSE を含む CQ 5.5 が、100(CONTINUE)またはエラーコードで即座に応答します。その他のサーブレットコンテナも、このメカニズムをサポートする必要があります。
このオプションは、通常は必要ありません。このオプションを使用する必要があるのは、次のログメッセージが表示された場合だけです。
Error while reading response: Interrupted system call
システムコールの対象が NFS 経由でアクセスするリモートシステム上にある場合、ファイルシステムからのシステムコールはすべて EINTR
で中断される可能性があります。これらのシステムコールがタイムアウトするか中断されるかは、基盤となるファイルシステムがローカルマシンにどのようにマウントされたかに基づきます。
以下を使用: /ignoreEINTR
インスタンスにそのような設定があり、ログに次のメッセージが含まれる場合は、パラメーターを指定します。
Error while reading response: Interrupted system call
内部的に、Dispatcher は次のように表現できるループを使用して、リモートサーバー(AEM)からの応答を読み込みます。
while (response not finished) {
read more data
}
このようなメッセージは、「EINTR
」セクションで read more data
が発生した場合に生成されることがあります。原因は、データの受信前にシグナルを受信したことです。
このような中断を無視するには、次のパラメーターを dispatcher.any
(/farms
の前)に追加します。
/ignoreEINTR "1"
/ignoreEINTR
を "1"
に設定すると、Dispatcher は応答全体が読み込まれるまでデータの読み込みを続行します。デフォルト値は 0
オプションを無効にします。
Dispatcher 設定ファイルのいくつかのセクションでは、glob
プロパティをクライアント要求の選択条件として使用します。の値 glob
プロパティとは、要求されたリソースのパスやクライアントの IP アドレスなど、Dispatcher が要求の側面と比較するパターンです。 例えば、/filter
セクションのアイテムは、 パターンを使用して、Dispatcher が従う、または拒否するページのパスを識別します。glob
この glob
の値には、ワイルドカード文字と英数字を含めて、パターンを定義できます。
ワイルドカード文字 | 説明 | 例 |
---|---|---|
* |
文字列に含まれる任意の文字の 0 個以上の連続するインスタンスに一致します。一致の最後の文字は、次のどちらかの状況によって判断されます。 文字列内のある文字がパターン内の次の文字に一致し、パターンの文字が以下の性質を持つ。
|
*/geo* /content/geometrixx ノードと /content/geometrixx-outdoors ノードの下にあるすべてのページに一致します。以下の HTTP 要求は、glob パターンに一致します。
*outdoors/* /content/geometrixx-outdoors ノードの下にあるすべてのページに一致します。例えば、次の HTTP 要求は glob パターンに一致します。
|
? |
任意の 1 文字に一致します。文字クラス外で使用します。文字クラス内のこの文字は、リテラルとして解釈されます。 | *outdoors/??/* geometrixx-outdoors サイトのすべての言語のページに一致します。例えば、次の HTTP 要求は glob パターンに一致します。
次の要求は glob パターンに一致しません。
|
[ and ] |
文字クラスの最初と最後を定めます。文字クラスには、1 つまたは複数の文字範囲および単一の文字を含めることができます。 ターゲット文字が文字クラス内または定義されている範囲内のいずれかの文字に一致する場合、一致が発生します。 閉じ角括弧が含まれない場合、パターンによって一致は発生しません。 |
*[o]men.html* 次の HTTP 要求に一致します。
次の HTTP 要求に一致しません。
*[o/]men.html* 次の HTTP 要求に一致します。
|
- |
文字の範囲を定めます。文字クラス内で使用します。文字クラス外のこの文字は、リテラルとして解釈されます。 | *[m-p]men.html* 次の HTTP 要求に一致します。
|
! |
続く文字または文字クラスを打ち消します。文字クラス内の文字および文字範囲の打ち消しにのみ使用してください。ワイルドカード文字 ^ wildcard .文字クラス外のこの文字は、リテラルとして解釈されます。 |
*[ !o]men.html* 次の HTTP 要求に一致します。
次の HTTP 要求に一致しません。
*[ !o!/]men.html* 次の HTTP 要求に一致しません。
|
^ |
続く文字または文字範囲を打ち消します。文字クラス内の文字および文字範囲の打ち消しにのみ使用してください。! ワイルドカードに相当します。文字クラス外のこの文字は、リテラルとして解釈されます。 |
ワイルドカード文字 ! の例と同様、サンプルパターンの文字 ! が 文字 ^ に置き換えられます。 |
Web サーバー設定で、次の属性を設定できます。
詳しくは、Web サーバーのドキュメント、および使用する Dispatcher インスタンスの readme ファイルを参照してください。
Apache の交替されるログ/パイプ経由のログ
Apache Web サーバーを使用している場合、交替されるログ(パイプ経由のログ)の標準的な機能を使用できます。例えば、次のようにパイプ経由のログを使用できます。
DispatcherLog "| /usr/apache/bin/rotatelogs logs/dispatcher.log%Y%m%d 604800"
この設定により、ログが自動的に次のように交替されます。
logs/dispatcher.log%Y%m%d
) をクリックします。ログの交替やパイプ経由のログについては、Apache Web サーバーのドキュメント(Apache 2.4 など)を参照してください。
インストール時のデフォルトのログレベルは高(レベル 3 = デバッグ)なので、Dispatcher ですべてのエラーおよび警告がログに記録されます。このログレベルは、初期の段階では非常に便利です。
ただし、追加のリソースが必要となるので、Dispatcher が現在の要件で円滑に動作している場合は、ログレベルを低くしてください。**
Dispatcher の機能強化の中で、バージョン 4.2.0 ではトレースログも導入されています。
トレースログはデバッグログよりレベルが高く、ログに追加情報が表示されます。以下に関するログが追加されます。
Web サーバーでログレベルを 4
に設定して、トレースログを有効にすることができます。
トレースを有効にしたログの例を以下に示します。
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Host] = "localhost:8443"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[User-Agent] = "curl/7.43.0"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Accept] = "*/*"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Client-Cert] = "(null)"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Via] = "1.1 localhost:8443 (dispatcher)"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-For] = "::1"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL] = "on"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Cipher] = "DHE-RSA-AES256-SHA"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Session-ID] = "ba931f5e4925c2dde572d766fdd436375e15a0fd24577b91f4a4d51232a934ae"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-Port] = "8443"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Server-Agent] = "Communique-Dispatcher"
ブロックルールに一致するファイルが要求されると、イベントがログに記録されます。
[Thu Mar 03 14:42:45 2016] [T] [11831] 'GET /content.infinity.json HTTP/1.1' was blocked because of /0082
Web サーバー、Dispatcher および AEM インスタンスの基本の操作とやり取りを確認するには、次の手順を実行します。
loglevel
を 3
.に設定します。
Web サーバーを起動します。これに伴い、Dispatcher も起動します。
AEM インスタンスを起動します。
Web サーバーと Dispatcher のログファイルおよびエラーファイルを確認します。
[Thu May 30 05:16:36 2002] [notice] Apache/2.0.50 (Unix) configured
および[Fri Jan 19 17:22:16 2001] [I] [19096] Dispatcher initialized (build XXXX)
Web サーバー経由で Web サイトにアクセスします。コンテンツが要求どおりに表示されていることを確認します。
例えば、AEM がポート 4502
で、Web サーバーがポート 80
で実行されているローカルインストール上で、以下の両方を使用して Web サイトコンソールにアクセスします。
https://localhost:4502/libs/wcm/core/content/siteadmin.html
https://localhost:80/libs/wcm/core/content/siteadmin.html
キャッシュディレクトリがいっぱいになっていることを確認します。
ページをアクティベートし、キャッシュが正常にフラッシュされるかを確認します。
すべて適切に動作している場合は、loglevel
を再び 0
に設定します。
複雑な設定をおこなう場合は、複数の Dispatcher を使用できます。例えば、次のように使用できます。
この場合、各要求が経由する Dispatcher は 1 つだけにしてください。別の Dispatcher から渡された要求は処理されません。したがって、どちらの Dispatcher も AEM Web サイトに直接アクセスするようにしてください。
ヘッダー X-Dispatcher-Info
を リクエスト に追加する場合、Dispatcher は、ターゲットがキャッシュされたか、キャッシュから返されたか、またはキャッシュ不可能であるかを返します。応答ヘッダー X-Cache-Info
には、この情報が読み取り可能な形式で格納されます。これらの応答ヘッダーを使用して、Dispatcher によってキャッシュされた応答に関する問題をデバッグできます。
この機能はデフォルトで有効になっていないため、応答ヘッダー X-Cache-Info
を含めるには、ファームに次のエントリが含まれている必要があります。
/info "1"
以下に例を挙げます。
/farm
{
/mywebsite
{
# Include X-Cache-Info response header if X-Dispatcher-Info is in request header
/info "1"
}
}
また、X-Dispatcher-Info
ヘッダーに値は必要ありませんが、テストに curl
を使用する場合は、ヘッダーを送信するために次のような値を指定する必要があります。
curl -v -H "X-Dispatcher-Info: true" https://localhost/content/wknd/us/en.html
以下は、X-Dispatcher-Info
によって返される応答ヘッダーの一覧です。
cache.docroot
)内に表示されます。_YYYYXXXXXX
が追加サれた名前です。Y
と X
が置き換えられ、一意の名前が作成されます。/test.html/a/path
)。sessionmanagement
ノードが含まれている)、リクエストに適切な認証情報が含まれていません。allowAuthorized 0
)が許可されておらず、リクエストに認証情報が含まれている。/test.html/a/file.ext
への要求が最初におこなわれ、その要求にキャッシュ可能な出力が含まれていると、Dispatcher は /test.html
への後続の要求の出力をキャッシュできなくなります。sessionmanagement
ノードが含まれている)、ユーザーセッションが無効であるか、有効でなくなっています。no_cache
Dispatcher: no_cache
ヘッダー。dispatcher による出力のキャッシュが禁止されています。