Adobe Experience Manager のクロスオリジンリソース共有(CORS)を使用すると、AEM 以外の web プロパティを使用して、認証済みおよび未認証の両方で AEM へのクライアントサイド呼び出しを行い、コンテンツを取得したり、AEM と直接やり取りしたりできます。
CORS 設定は、AEM で OSGi 設定ファクトリとして管理され、各ポリシーはファクトリの 1 つのインスタンスとして表されます。
http://<host>:<port>/system/console/configMgr > Adobe Granite Cross Origin Resource Sharing Policy
Adobe Granite Cross-Origin Resource Sharing Policy(com.adobe.granite.cors.impl.CORSPolicyImpl
)
ポリシーは、
Allowed Origin
と Origin
リクエストヘッダーAllowed Paths
とリクエストパスに比較することで選択されます。これらの値に一致する最初のポリシーが使用されます。 何も見つからない場合、CORS リクエストが却下されます。
ポリシーがまったく設定されていない場合、サーバーの他のモジュールが CORS に応答しない限り、ハンドラーが無効になり、事実上拒否されるため、CORS リクエストも応答されません。
"alloworigin" <origin> | *
origin
パラメーターのリスト。リクエストに資格情報がない場合、サーバーは * をワイルドカードとして使用することで、任意の接触チャネルがリソースにアクセスできるようになります。 実稼動環境で Allow-Origin: *
を使用することは絶対にお勧めできません。これを使用すると、すべての外国(つまり、攻撃者)の web サイトに対して、CORS のないリクエストを実行を許可してしまいます。"alloworiginregexp" <regexp>
regexp
正規表現のリスト。正規表現は、慎重に構築されない場合、意図しない一致を引き起こす可能性があり、攻撃者は、ポリシーにも一致するカスタムドメイン名を使用できます。 alloworigin
を使用して、特定の接触チャネルホスト名ごとに個別のポリシーを設定することをお勧めします。これが他のポリシー プロパティの設定を繰り返すことを意味する場合でも同様です。接触チャネルが異なると、ライフサイクルや要件が異なるので、明確に分離することに役立ちます。"allowedpaths" <regexp>
regexp
正規表現のリスト。"exposedheaders" <header>
"maxage" <seconds>
seconds
パラメーター。"supportedheaders" <header>
header
パラメーターのリスト。"supportedmethods"
"supportscredentials" <boolean>
boolean
。プリフライトリクエストへの応答として使用する場合、これは、資格情報を使用して実際のリクエストを実行できるかどうかを示します。サイト 1 は、コンテンツが GET を介して消費される、匿名でアクセス可能な読み取り専用の基本的なシナリオです。
{
"supportscredentials":false,
"exposedheaders":[
""
],
"supportedmethods":[
"GET",
"HEAD",
"OPTIONS"
],
"alloworigin":[
"http://127.0.0.1:3000",
"https://site1.com"
],
"maxage:Integer": 1800,
"alloworiginregexp":[
"http://localhost:.*"
"https://.*\.site1\.com"
],
"allowedpaths":[
"/content/_cq_graphql/site1/endpoint.json",
"/graphql/execute.json.*",
"/content/site1/.*"
],
"supportedheaders":[
"Origin",
"Accept",
"X-Requested-With",
"Content-Type",
"Access-Control-Request-Method",
"Access-Control-Request-Headers",
]
}
サイト 2 はより複雑で、承認および変更(POST、PUT、DELETE)リクエストが必要です。
{
"supportscredentials":true,
"exposedheaders":[
""
],
"supportedmethods":[
"GET",
"HEAD"
"POST",
"DELETE",
"OPTIONS",
"PUT"
],
"alloworigin":[
"http://127.0.0.1:3000",
"https://site2.com"
],
"maxage:Integer": 1800,
"alloworiginregexp":[
"http://localhost:.*"
"https://.*\.site2\.com"
],
"allowedpaths":[
"/content/site2/.*",
"/libs/granite/csrf/token.json",
],
"supportedheaders":[
"Origin",
"Accept",
"X-Requested-With",
"Content-Type",
"Access-Control-Request-Method",
"Access-Control-Request-Headers",
"Authorization",
"CSRF-Token"
]
}
Dispatcher 4.1.1 以降の応答ヘッダーはキャッシュ可能です。 これにより、リクエストが匿名である限り、CORS でリクエストされたリソースとともに CORS ヘッダーをキャッシュできます。
一般に、Dispatcher でのコンテンツのキャッシュに関する考慮事項と同じ点を、Dispatcher での CORS 応答ヘッダーのキャッシュに適用できます。 次の表は、CORS ヘッダー(CORS リクエスト)をキャッシュできるタイミングを定義します。
キャッシュ可能 | 環境 | 認証ステータス | 説明 |
---|---|---|---|
いいえ | AEM パブリッシュ | 認証済み | AEM オーサー上の Dispatcher キャッシュは、オーサリングされていない静的アセットに限定されます。このため、HTTP 応答ヘッダーを含む AEM オーサー上のほとんどのリソースをキャッシュするのは困難であり、実用的ではありません。 |
いいえ | AEM パブリッシュ | 認証済み | 認証済みリクエストでは CORS ヘッダーをキャッシュしないでください。リクエスト元ユーザーの認証/承認ステータスが配信済みリソースにどのような影響を与えるかを判断するのは困難なので、これは、認証済みリクエストをキャッシュしないという一般的なガイダンスに従っています。 |
はい | AEM パブリッシュ | 匿名 | Dispatcher でキャッシュ可能な匿名リクエストは、応答ヘッダーもキャッシュできるので、今後の CORS リクエストで、キャッシュされたコンテンツにアクセスできるようになります。AEM パブリッシュで CORS 設定を変更した場合は、影響を受けるキャッシュ済みリソースを無効化する必要があります 。影響を受ける可能性のあるキャッシュ済みコンテンツを判断するのは難しいので、ベストプラクティスとしては、コードまたは設定のデプロイメントについては Dispatcher キャッシュをパージするように推奨されています。 |
CORS ヘッダーのキャッシュを許可するには、すべてのサポート AEM パブリッシュの dispatcher.any ファイルに以下の設定を追加します。
/myfarm {
...
/headers {
"Origin"
"Access-Control-Allow-Origin"
"Access-Control-Expose-Headers"
"Access-Control-Max-Age"
"Access-Control-Allow-Credentials"
"Access-Control-Allow-Methods"
"Access-Control-Allow-Headers"
}
...
}
dispatcher.any
ファイルを変更をしたら、web サーバーアプリケーションを必ず再起動します。
/cache/headers
設定の更新後、次のリクエストでヘッダーが適切にキャッシュされるように、キャッシュの完全なクリアが必要になる可能性があります。
ログは com.adobe.granite.cors
で利用できます。
DEBUG
を有効にすると、CORS リクエストが拒否された理由の詳細が表示されます。TRACE
を有効にすると、CORS ハンドラーを通じて実行されるすべてのリクエストの詳細が表示されます。Access-Control-Allow-Origin
ヘッダーがない場合、com.adobe.granite.cors
の DEBUG で拒否のログを確認します。/cache/headers
設定が dispatcher.any
に適用されており、web サーバーが正常に再起動されることを確認します。