iFrameに埋め込む
待機室が訪問者の進捗を追跡する方法のため、待機室をiFrameに適切に埋め込むには、特定のクッキー属性を指定する必要があります。
クッキーのSameSite属性 ↗は、そのクッキーが同じページに読み込まれる他のドメイン(広告バナー、iFrames)と共有できるかどうかを指定します。デフォルトでは、ブラウザは攻撃者がクッキーに存在する情報を盗んだり操作したりするのを防ぐために、クロスサイトのサブリクエストでクッキーを送信しません。
しかし、この動作は、待機室がiFrameに埋め込まれている場合、ユーザーを適切にキューに入れることを妨げる可能性があります。待機室は、キュー内のユーザーを追跡するために__cfwaitingroomクッキーに依存しています。しかし、ブラウザはデフォルトでクッキーが待機室に到達するのをブロックするため、アクティブでキューに入っている待機室はユーザーをキューに入れることができず、アプリケーションにアクセスさせることはありません。
待機室がクッキーにどのように応答するかをカスタマイズするには、待機室を作成する際に ↗ cookie_attributesオブジェクトを含めます(API経由のみ利用可能)。
利用可能なオプションは以下の通りです:
-
samesite: 待機室クッキーのSameSite属性を設定します:- auto(デフォルト):できるだけ柔軟にすることを目的としており、デフォルトはlaxですが、Always Use HTTPSを有効にするとnoneになります。
- lax:通常のクロスサイトのサブリクエスト(たとえば、サードパーティサイトに画像やフレームを読み込むため)ではクッキーは送信されませんが、ユーザーがオリジンサイトに移動する際には送信されます。
- strict:クッキーはファーストパーティのコンテキストでのみ送信されます。
- none:クッキーは常に送信されます。
-
secure: 待機室クッキーのSecure属性を設定し、リクエストがhttps経由で行われることを要求します:- auto(デフォルト):できるだけ柔軟にすることを目的としており、デフォルトはneverですが、Always Use HTTPSを有効にするとalwaysになります。
- always:クッキーは
httpsリクエストを使用してのみ送信できます。 - never:クッキーは
httpまたはhttpsリクエストを使用して送信できます。
待機室をiFrameに埋め込む場合、待機室を作成する際に ↗ cookie_attributesオブジェクトに以下の値を指定します(API経由のみ利用可能):
samesite:nonesecure: Always Use HTTPSを有効にしている場合はautoに設定します。無効にしている場合はalwaysに設定します。
リクエスト
curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/waiting_rooms" \--header "Authorization: Bearer <API_TOKEN>" \--header "Content-Type: application/json" \--data '{ "name": "shop_waiting_room", "description": "ウェブショップの待機室", "host": "shop.example.com", "path": "/shop", "queue_all": true, "new_users_per_minute": 200, "total_active_users": 300, "session_duration": 1, "disable_session_renewal": false, "json_response_enabled": false, "queueing_method": "FIFO", "cookie_attributes": { "samesite": "none", "secure": "auto" }}'レスポンス
{ "success": true, "errors": [], "messages": [], "result": [ { "id": "1111111111111111111111", "created_on": "2021-01-01T05:20:00.12345Z", "modified_on": "2021-01-01T05:20:00.12345Z", "name": "shop_waiting_room", "description": "ウェブショップの待機室", "host": "shop.example.com", "path": "/shop", "queue_all": true, "new_users_per_minute": 200, "total_active_users": 300, "session_duration": 1, "disable_session_renewal": false, "json_response_enabled": false, "queueing_method": "FIFO", "cookie_attributes": { "samesite": "none", "secure": "auto" } } ]}主要なウェブブラウザは、iFrame内の待機室で使用されるのと同じタイプのクッキーに対して制限を導入しています。待機室は、これらの制限を回避するために独立したパーティション状態を持つクッキー(CHIPS) ↗を使用していますが、いくつかの欠点があります:
- iFrame内と外で待機室を表示しているユーザーは、2つの別々のユーザーとして扱われ、それぞれのインスタンスが異なる時間にキューを退出し、分析で別々にカウントされる可能性があります。
- 待機室をiFrameに埋め込むには、埋め込まれたページと埋め込むページの両方がHTTPS経由でアクセスされる必要があります。
- CHIPSは、サードパーティのクッキーのブロックが設定で無効になっていない限り、SafariやSafari派生のブラウザ(OrionやほとんどのiOSブラウザ)ではサポートされていません。これらのユーザーはキューの最後に留まり、キューが空になるまで進むことができず、分析で複数回カウントされる可能性があります。
一般的に、待機室クッキーの設定や取得に問題がある場合、ユーザーはキューの最後に留まり、分析で複数のユーザーとしてカウントされることを期待する必要があります。
これらの制限は、埋め込まれたページと埋め込むページが共通のドメイン名を共有している場合には適用されない可能性があります。たとえば、example.comのページがshop.example.comの待機室を埋め込む場合、ブラウザによってファーストパーティと見なされ、サードパーティのクッキー制限の対象にならない可能性があります。