MakeでCAPTCHAタスクAPIを使用する

まず、対象ホスト名の有効なプロファイルをワークスペースに設定します。site と action を送信しても、プロファイルは作成されません。対象がまだ設定されていない場合は、サイトプロファイルの設定を参照してください。

1. 1.

   HTTP v4 の認証を設定する

   認証タイプに API key を選択し、認証情報のキーチェーンを作成します。キーには Bearer、スペース、ワークスペースの API キーの順で指定し、配置場所を In the header、パラメーター名を Authorization に設定します。許可するサービスオリジンを https://api.solvethree.com に制限してください。キーはシナリオのデータで受け渡すのではなく、キーチェーンに保持してください。

2. 2.

   リクエスト設定を入力する

   以下のメソッド、URL、クエリパラメーター、ヘッダー、JSON ボディを使用します。それぞれ対応するモジュールのフィールドに入力してください。JSON リクエストの内容に指定するのは body の中身だけです。例全体は設定の説明であり、インポート可能な Make のブループリントではありません。

{
  "method": "POST",
  "url": "https://api.solvethree.com/v1/tasks",
  "query": {
    "waitMs": "0"
  },
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "site": "accounts.example.com",
    "action": "login",
    "proxy": "http://USER:PASSWORD@PROXY:PORT",
    "requestId": "one-stable-id-for-this-logical-job"
  },
  "authentication": {
    "type": "API key",
    "Key": "Bearer YOUR_PRIVATE_WORKSPACE_KEY",
    "API key placement": "In the header",
    "API key parameter name": "Authorization",
    "Allowed service origins": [
      "https://api.solvethree.com"
    ]
  }
}

• site を設定済みのホスト名に置き換えます。完全な URL ではありません。action には対象フローで使われるアクションを設定します。
• proxy を使用するプロキシの URL に置き換えます。リクエストには proxy または proxyCandidates のどちらか一方だけが必要です。この例では単一のプロキシを使用します。
• 新しい論理ジョブごとに固有の requestId を割り当て、復旧用に保持してください。例の値はプレースホルダーであり、無関係なジョブ間で使い回す ID ではありません。
• この reCAPTCHA リクエストに type や url を追加しないでください。recaptchaType を省略すると、デフォルトの enterprise-v3 になります。

作成に成功したレスポンスを受け取ったら、次の処理に進む前に、返されたタスク ID を論理ジョブに紐付けて保存します。そのタスクを取得するための HTTP リクエストモジュールを別途追加してください。

タスクのステータスで振り分ける前に、成功以外の HTTP レスポンスを処理してください。HTTP エラーと、ステータスが failed のタスクは別物です。読み取れないレスポンスや成功していないレスポンスを、単なる pending の結果として扱わないでください。

GET が成功したら、返された status に対する明示的なフィルターを備えたルーターを追加します。成功した HTTP レスポンスをすべて解決結果のルートに流さないでください。

未完了タスク用のフィルターは、その他すべてを受け入れるものにせず、条件を明示してください。ステータスが欠落している場合や想定外の場合は、黙って無期限にポーリングするのではなく、内容を確認する必要があります。失敗ルートでは、別のタスクを作成する前に報告されたエラーを調査してください。無効な入力を変更せずに再試行しても改善しません。

単純で上限のある設計では、ポーリングの各実行で GET を一度行います。未完了の処理は、次の実行から読み取れる場所に保存してください。現在の実行内にしか存在しないタスク ID に依存しないでください。

1. 1.

   開始経路を選ぶ

   ジョブにすでにタスク ID がある場合は、直接 GET に進みます。作成経路に進めるのは、既存のタスクがない新しいジョブだけです。

2. 2.

   未完了のまま実行を終了する

   pending または solving の場合は、タスク ID を保持して実行を終了します。再開時には同じ ID を取得します。終了状態のタスクはクローズ済みにし、後のポーリング実行で結果が再処理されないようにしてください。

3. 3.

   リピーターに上限を設定する

   代わりにリピーターを追加する場合は、有限の最大回数を設定し、保存した ID に対する GET だけを繰り返してください。ready または failed になった後は、追加のポーリングや結果処理を行わないようにします。繰り返しの上限に達したら、停止して ID を保持します。代わりのタスクを作成するわけではありません。

この reCAPTCHA リクエストで送信する値は、タスク ID ではなく solution.token です。目的の対象に送信する際は、返されたブラウザー識別情報の userAgent と secChUa を、解決に成功したプロキシとともに使用してください。

最終リクエストで、Make の HTTP モジュールが解決時に使った顧客側のプロキシを使用できるとは限りません。必要なプロキシとブラウザー識別情報に対応したクライアントに ready の結果を渡してください。ready は解決結果が生成されたことを意味します。受け入れられたかどうかは、その後の送信に対する対象側のレスポンスで決まります。