解決後にTicketmasterが403を返す場合の確認事項

api.solvethree.com が HTTP 403 を返しました。

ドキュメントに記載されている、プロファイルが無効な場合の 403 は reCAPTCHA に適用されます。Kasada と TMPT は別のタスクタイプを使用し、reCAPTCHA のサイトプロファイルは必要ありません。送信したタスクの本文を確認し、API レスポンスを読んでください。

試してみましょう： reCAPTCHA の場合は、正しいサイトプロファイルを有効にしてください。Kasada と TMPT はそれぞれ独自のタイプと URL を使用し、そのプロファイルは必要ありません。タスクの形式が正しいのに 403 が返される場合は、サポートにお問い合わせください。

API リクエストは成功しましたが、タスクは失敗しています。

タスクの errorCode と error を確認してください。HTTP レスポンスのステータスと、タスクが最終的に失敗することは、別のエラーです。

試してみましょう： そのタスクのポーリングを停止し、報告されたエラーに対処してから再試行してください。解決に失敗した場合は返金されます。無効な入力を変更せずに送信し続けないでください。

タスクは ready ですが、Ticketmaster が HTTP 403 を返しました。

Ticketmaster に送信するリクエストを確認してください。ready のタスクには使用可能な解決結果が含まれていますが、後続の送信先で受け入れられることを保証するものではありません。

試してみましょう： 以下の URL、解決結果の設定場所、プロキシ、ブラウザー識別情報を確認してください。送信先の 403 だけでは、どの保護機能がリクエストを拒否したかは特定できません。

タスクの入力と、Ticketmaster が拒否したリクエストを比較してください。別の URL 向けの解決結果は代わりになりません。また、TMPT Cookie と Kasada ヘッダーは相互に置き換えられません。

• アクションが Event の TicketmasterTmptTask には、正確なイベント URL を使用してください。
• アクションが Login の TicketmasterTmptTask には、サインインの開始 URL を使用してください。
• KasadaTask には、www.ticketmaster.com 上の意図した HTTPS 対象 URL を使用してください。これは、スタンドアロンの Kasada で現在サポートされているホスト名です。

連携先が Cookie を必要としているのに Kasada タスクを作成した場合、またはヘッダーを必要としているのに TMPT タスクを作成した場合は、出力を変換しようとせず、タスクタイプを修正してください。リクエストにどちらの出力が必要か不明な場合は、TMPT と Kasada の比較を参照してください。

HTTP クライアントに渡した変数だけでなく、送信リクエストを確認してください。古い Cookie やクライアントのデフォルト設定により、アプリケーションが意図したものとは異なるリクエストになる場合があります。

TMPT は ready ですが、リクエストが拒否されます。

意図した Ticketmaster リクエストで、返された値が tmpt Cookie として送信されていることを確認してください。古い Cookie や、別のフィールドに設定されたトークンになっていないかを確認します。

試してみましょう： 返された生の値を tmpt Cookie として送信してください。これは reCAPTCHA トークンでも Kasada ヘッダーオブジェクトでもありません。TMPT 連携ガイドを参照してください。

Kasada は ready ですが、リクエストが拒否されます。

送信ヘッダーを、返されたヘッダーオブジェクト全体と比較してください。省略された値や上書きされた値がないかを確認します。

試してみましょう： 返されたヘッダーを、意図した対象リクエストにまとめて適用してください。1 つのヘッダーだけを選ばないでください。Kasada ヘッダーガイドを参照してください。

アプリケーションが別のプロキシ経由で送信しています。

アプリケーションの出口と、解決結果の生成に成功したプロキシを比較してください。proxyCandidates を指定した場合、最初の候補が成功したと決めつけないでください。

試してみましょう： 対象リクエストには、成功したプロキシを使用してください。

クライアントが独自のブラウザー識別情報を使用しています。

クライアントのデフォルト設定が、返された userAgent または secChUa を上書きしていないか確認してください。

試してみましょう： 返されたブラウザー識別情報を、成功したプロキシと意図した対象 URL とともに使用してください。無関係なユーザーエージェントやクライアントヒントと組み合わせないでください。

これらを確認しても拒否の原因がわからない場合は、次の情報を添えて [email protected] にお問い合わせください。

• タスク ID と、提供されている場合は requestId。
• 製品またはタスクタイプと、失敗時のタイムスタンプ。
• エラーを返したホスト、その HTTP ステータス、およびタスクの errorCode と error があればその内容。
• 対象ホスト名とアクション。TMPT の場合は Event または Login。
• 機密情報を除いたレスポンスの説明と、URL、Cookie またはヘッダー、プロキシ、ブラウザー識別情報について実施済みの確認事項。

レポートを送信する前に、API キー、プロキシのパスワード、トークン、Cookie、顧客データを削除してください。