在 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，并保留以便恢复。示例值是占位符，不应在无关作业之间复用。
• 不要在此 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 请求，应提交的值是 solution.token，而非任务 ID。向预期目标提交时，请使用返回的 userAgent 和 secChUa 浏览器身份信息，并使用成功解题时的代理。

不要假定 Make 的 HTTP 模块能在最终请求中使用解题时的客户代理。将就绪结果交给支持所需代理和浏览器身份信息的客户端。ready 表示已生成解题结果；是否被接受取决于目标对后续提交的响应。