验证码是如何工作的？

Scrapeless Agent Browser 包括在用于网络自动化的浏览器会话中处理 CAPTCHA。

CAPTCHA 通过收集关于交互的证据并检查该证据是否满足服务的人类验证政策来工作。在可见的挑战中，用户可能会识别图像或输入显示的文本。其他系统在几乎没有可见努力的情况下评估交互。重要的实施边界在于浏览器中发生的事情和受保护的应用程序服务器接受的内容之间。

页面上的复选标记是一个用户界面事件。它本身并不能证明应用程序已验证响应或批准请求的操作。一个可靠的集成将挑战结果连接到服务器端验证，然后连接到业务操作，例如接受表单。

验证流程中的参与者

一个典型的托管 CAPTCHA 集成涉及访问者的浏览器、受保护的应用程序和挑战提供者。浏览器显示或运行挑战。提供者评估回应并提供结果或响应令牌。应用程序的服务器在决定是否继续之前验证该证据。

这些责任应保持明确。浏览器无法安全地保存应用程序的验证秘密，客户端成功标志不应被视为权威证据。服务器还需负责常规检查，例如字段验证、帐户权限和重复提交处理。

一个有用的实现图应显示表单提交将响应令牌携带到应用程序，随后是一个服务器到服务器的验证步骤。然后应用程序记录其决策。省略那一步骤会产生看似受保护的界面，同时使后续操作依赖于客户端控制的输入。

一个拼图出现之前会发生什么

一个挑战系统可以在决定是否显示互动任务之前评估上下文。确切的信号和决策过程因产品和配置而异。复选框的存在并不意味着系统仅依赖于用户点击的位置，而难题的缺失并不证明没有进行验证。

避免将每个结果归因于单一行为，例如光标移动。使用键盘或辅助技术的访问者仍然是合法用户。一个将一种首选交互模式视为普遍的系统有排除其他浏览器和输入方式行为不同的人的风险。

对于应用程序团队而言，实际问题是提供者暴露了哪些结果，以及每个结果意味着什么。区分成功完成的挑战、拒绝的响应、缺失的响应以及技术上无法完成验证的情况。这些状态可能需要不同的用户消息，即使没有一个应该自动允许受保护的操作继续。

响应令牌和服务器验证

响应令牌是通过特定验证交互产生的证据，受提供者的限制。应用程序将该令牌发送到提供者的验证服务，并检查返回的结果。令牌应该被视为敏感的短期值，而不是访问者永久为人类的可靠证据。

规则： 1. 仅输出翻译后的文本——没有解释，没有额外的包裹代码块。 2. 完全保留Markdown/HTML结构（标题、列表、链接、表格）。 3. 保持任何占位符令牌如@@CODEBLOCK_0@@或@@INLINECODE_0@@完全不变；绝不要翻译、重新排序、合并或重新格式化它们。 4. 不要添加或删除```代码块，也不要将普通文本包装到代码块中。 reCAPTCHA 响应验证 需要后端验证，其响应令牌为一次性，有效期为两分钟。那些规则属于该产品；不要假设每个 CAPTCHA 实现使用相同的生命周期或响应字段。

遵循所选提供商的要求，验证结果和返回的任何上下文字段。与不同网站或操作相关的有效令牌不应仅仅因为某个布尔字段显示成功而被接受。必须与集成进行精确检查，而不是从另一个提供商复制的一般示例。

应用程序仍然做出最终决策

CAPTCHA 完成是应用程序决定的一个输入。应用程序仍然可能拒绝无效的表单、禁止的帐户操作或超出其访问政策的请求。人工验证并不取代身份验证、授权或业务规则。

这种分离在一个示例性的账户注册流程中是显而易见的。访问者可以正确完成一个挑战，但提交的电子邮件地址未通过格式验证。表单应该解释该字段错误而不暗示 CAPTCHA 是错误的。相反，当缺少挑战验证时，应该不允许提交有效的电子邮件地址。

使用以下文本的中文翻译： 规则： 1. 仅输出翻译文本 - 不要解释，不要额外的封装代码块。 2. 完全保留Markdown/HTML结构（标题、列表、链接、表格）不变。 3. 保持任何占位符标记，例如@@CODEBLOCK_0@@或@@INLINECODE_0@@，保持完全不变；绝不要翻译、重排、合并或重新格式化它们。 4. 不要添加或删除```代码块，也不要将普通文本包装在代码块中。 HTTP 响应模型 以连贯的方式报告结果，同时保持响应主体足够具体，以便应用程序能够呈现正确的状态。不要仅仅因为浏览器接收到一个具有成功传输状态的页面就推断成功。

为什么一个完成的挑战仍然会失败

一个完成的挑战在应用边界可能会失败，如果响应已过期、已被消费或与预期的集成上下文不匹配。页面也可能在结果可用之前提交。这些是不同的失败模式，需要分别的诊断标签。

一个长表单说明了时间问题。如果验证发生在开始阶段，而访客花费大量时间填写其他字段，当表单提交时证据可能不再有效。设计交互时，确保验证对应于实际保护行为，使用提供者支持的生命周期。

多个标签和重复提交引入了另一类混淆。每个表单实例应该跟踪自己的状态，服务器应将验证结果与预期操作关联。避免在分析事件或支持截图中保存响应令牌，而是记录结果和内部关联标识符，而不是令牌本身。

可访问性是机制的一部分

CAPTCHA机制必须考虑到无法完成所选挑战格式的访客。图像识别可能会排除一些视觉障碍用户；音频任务可能会造成不同的障碍。提供替代格式只有在完整的交互与个人的设备和辅助技术可用时才有帮助。

W3C的 对CAPTCHA可访问性的分析 解释了为什么人类验证任务可能会施加不平等的负担。将可访问性视为选择和测试的输入，而不是挑战容器的外观变化。

测试焦点移动、标签、错误公告和当验证无法完成时的恢复路径。适当时保留用户的表单条目。访客不应该因为挑战过期而不得不重建一个长提交，界面应该解释下一个支持的步骤，而不暴露内部秘密。

测试整个验证链

CAPTCHA测试应覆盖在测试环境中有效和无效的结果。使用提供者的文档测试设施（如有）。一个仅检查小部件是否呈现的测试未检查服务器验证和业务决策阶段。

包括缺失的证据、被拒绝的证据、已消耗的证据以及有效验证后跟随无效业务输入。确认应用程序准确报告每种情况。检查保护操作是否无法通过省略验证步骤的第二个提交路径到达。

保持测试证据的范围在其证明的内容内。成功的测试模式挑战表明集成遵循预期流程；它不衡量生产机器检测的准确性。同样，已完成小部件的截图是有用的界面证据，但无法显示后端是否强制执行验证。

观察浏览器自动化中的CAPTCHA

浏览器自动化应区分请求的页面、挑战页面和拒绝访问结果。保存足够的非敏感上下文以确定发生了哪种状态：最终URL、可见标题，以及是否显示了预期内容。一个接受任何返回文本的解析器可能会意外地将挑战指令存储为目标文档。

使用产品文档控制会话，而不是假设挑战结果可以在不相关的浏览器上下文之间移动。在计划工作流程时，审查 当前服务定价 并测量可用目标内容，而不是执行的挑战交互的数量。

衡量集成是否有帮助

CAPTCHA集成应通过是否减少针对性滥用而评估，同时允许预期用户完成任务。仅完成率是不够的：严格的挑战可以抑制滥用提交和合法使用。比较对应用程序重要的结果。

按浏览器类型、输入方法和工作流阶段分解失败的交互，在这些测量适当且保护隐私时。有一个集中在最终提交行为上的失败可能表明令牌生命周期问题。集中在键盘用户中的失败可能表明界面不可访问。

为仍然被阻止的合法访客定义支持的升级路径。这可能是替代验证路线或与服务运营商联系。该机制应有一个操作所有者，可以调查整个链条，而不是要求用户猜测哪个浏览器设置导致拒绝。

结论

CAPTCHA通过证据收集链、响应验证和应用程序策略工作。整体构建和测试该链条。浏览器交互、提供者结果和最终业务操作每个需要一个明确的状态，因此可见的成功指示器永远不会成为重要操作的唯一保护。