tencent cloud

Tencent Cloud EdgeOne

ステップ4:クライアント認証の有効性を検証する

ダウンロード
フォーカスモード
フォントサイズ
最終更新日: 2026-10-15 18:07:47
AI翻訳
EdgeOne クライアント認証 SDK をアプリケーションで安定的に動作させるために、以下の主要指標を参照して統合が成功したかどうかを判断してください(順番に検証とトラブルシューティングを行うことを推奨します):

検証項目1:クライアントがEdgeOneエッジサービスにアクセスする

クライアント認証では、お客様のクライアントが EdgeOne サービスにアクセスする必要があります。お客様のビジネスで複数の CDN プロバイダーを使用している場合、EdgeOne を通じてサービスを提供している部分のみがクライアント認証をサポートします。
お客様が受信したレスポンスに、EO-LOG-UUID ヘッダーが含まれていることを確認してください。レスポンスにこのヘッダーが含まれていない場合、クライアントが EdgeOne 以外のサービスにアクセスした可能性があります。

検証項目2:SDKの正常な読み込み

SDK が正常に読み込まれた後にのみ、クライアント認証に必要なフローを完了できます。
SDK が正常に読み込まれた後、ビジネスドメインの /.eo-sec-bot/ サービスにアクセスして初期化を行います。このリクエストが確認できない場合、SDK の初期化に異常が発生している可能性があります。

検証項目3:クライアント認証ルール設定の完了

クライアント認証ルールは、ビジネスサービスがクライアントに対して要求する具体的な認証要件を定義します。お客様は クライアント認証ルールの設定 を完了した後にのみ、自動認証フローを実行できます。
クライアント認証ルールが正しく設定された後、クライアントが認証フローを実行せずに保護された API に直接アクセスした場合、HTTP 428 チャレンジレスポンスを受信します。このレスポンスには EO-Attest-Challenge ヘッダーが含まれます。
説明:
クライアント認証ルールが設定されていない場合でも、お客様はクライアントで attestWithParams() インターフェースを呼び出して、手動で認証フローを開始できます。ただし、サーバー側 API が保護されていないため、EdgeOne は認証資格情報を検証せず、HTTP 428 チャレンジにも応答しません。
クライアントが HTTP 428 チャレンジを受信しなかった場合は、以下のフローを参照してトラブルシューティングを行ってください:
1. クライアントの API リクエストが正しいドメイン名にアクセスしているかどうか
クライアントがアクセスするドメイン名が、EdgeOne の接続 CNAME に正しく解決され、EdgeOne のエッジノードアドレスに正常にアクセスできているかどうか。
2. クライアントリクエストが他のセキュリティポリシーによってブロックされているかどうか
クライアントが HTTP 567 などのブロックステータスコードを受信した場合は、レスポンス内の EO-LOG-UUID ヘッダー内容を記録し、Web セキュリティ分析でリクエスト ID をフィルタ条件として使用して照会し、具体的なブロック原因を確認してください。
3. クライアントの API リクエストがクライアント認証ルールに正しく一致しているかどうか
まず、アクセス対象のドメインがどの Web 保護ポリシー(サイトレベルポリシー、ドメインレベルポリシー、またはポリシーテンプレート)を使用しているかを確認する必要があります。サイトの Web 保護設定ページで、該当するポリシーを選択した後、さらに設定を確認してください。
次に、Bot 管理 > クライアント認証で、ルールが設定され有効化されているかどうかを確認します。ルールの一致条件には API リクエスト範囲が含まれている必要があり、ポリシー設定は対応するクライアントタイプをカバーしている必要があります。

検証項目4:クライアントがHTTP 428チャレンジを正しく処理する

クライアントはチャレンジレスポンスを正しく処理することで、適応型認証や認証更新などのフローを実行できます。
クライアントは HTTP 428 チャレンジレスポンスを受信した後、認証フローを実行し、その後リクエストを再送信します。
説明:
お客様のクライアント認証ルール設定で、1つの API リソースに複数の認証方式を使用している場合(例えば、1つの API リソースを保護するために複数のルールを設定している場合、または SDK チャレンジを使用して二次認証を行っている場合)、クライアントは複数回の HTTP 428 リクエストを受信します。クライアントが各チャレンジを処理し終えるたびに、必ずリクエストを再送信してください。

検証項目5:対話型認証のレンダリング(オプション)

お客様のアプリケーションがインタラクティブ認証(例:インタラクティブ Captcha)を使用している場合は、その UI が正しくレンダリングされ、ユーザー操作に応答することを確認してください。
認証フローをトリガーし、インタラクティブ認証のレンダリング位置を確認します。認証完了後、操作フローが正常に完了することを確認します。

ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック