reCAPTCHA与hCaptcha
Scrapeless通用抓取API支持在选定的CAPTCHA保护场景中进行授权的公共页面检索。
TL;DR
- reCAPTCHA与hCaptcha描述了一个特定的技术概念，而不是对用户或请求的完整判断。
- 可靠的诊断结合了来源证据、控制比较和受保护行为的上下文。
- 单个信号可以在不确定的情况下有用；误报需要审核和可访问的后备方案。
- 授权自动化应优先选择官方接口，最小化负载，并在操作员明确拒绝访问时停止。
- Scrapeless通用抓取API可以支持允许的公共数据工作流，但它不能替代同意、合同或法律审核。
定义
reCAPTCHA和hCaptcha是帮助网站评估请求或行为是否来自合法用户而不是不必要的自动化的服务。这两者都使用客户端集成生成响应令牌，并使用服务器端验证端点来验证该令牌。它们的产品级别、风险模型、挑战呈现、管理工具、数据实践和响应字段各不相同。明智的选择取决于受保护行为、可访问性要求、隐私审核、地理受众、操作控制和应用程序的令牌验证能力。
实际问题不仅在于术语的含义，还在于支持标签的证据、依赖于其的决定以及操作员如何处理不确定性。本指南将可观测行为与假设分开，以便开发人员、安全团队、数据工程师和技术买家能够准确使用该概念。
共享架构
这两个服务将浏览器端挑战执行与服务器端令牌验证分开。
该页面加载提供程序代码与公共站点密钥。在访客或浏览器完成所需检查后，集成在表单字段或回调中返回一个令牌。应用程序的后端将该令牌与其秘密凭证一起发送到提供者的验证端点。决定是否接受受保护行为的是后端，而不是浏览器。
这种共享模式使迁移成为可能，但并不使产品可互换。字段名称、脚本、窗口小部件容器、回调API、令牌规则、响应对象、管理控制台和企业功能各不相同。围绕有效、主机名、行为、得分和错误类别等小型内部结果构建提供者适配器。
reCAPTCHA模型和验证
reCAPTCHA在Google的服务系列下提供互动和基于得分的方法。
reCAPTCHA v2通常使用复选框，并可能呈现图像挑战。reCAPTCHA v3返回一个操作的得分，以便应用程序可以应用其自己的阈值和递增加政策。 Google reCAPTCHA验证指南 指出响应令牌必须在后端进行验证，是单次使用的，并且有短期有效性。
得分并不是人或机器人的普遍判决。团队必须根据其流量和行动的价值校准阈值。监控接受度、欺诈、放弃和地区行为。避免对登录、通讯邮件注册、支付和公共搜索使用一个阈值，因为错误的代价各不相同。
hCaptcha模型和验证
hCaptcha还将浏览器小部件与后端Siteverify请求结合在一起。
该 hCaptcha开发者指南 记录了h-captcha-response字段和POST到其验证端点的表单编码。其集成使用h-captcha容器和提供程序脚本，因此迁移需要模板、内容安全策略、后端、分析和测试变更。服务器验证仍然是强制性的。
应用程序应检查成功和其计划中可用的预期站点密钥或主机名数据，处理文档中的错误，并将秘密保留在客户端代码之外。测试密钥仅适用于非生产环境，因为它们不能提供真实的保护。
可访问性、隐私和用户体验
最佳的CAPTCHA选择是在保护操作的同时排除最少的合法用户。
该 W3C CAPTCHA可访问性说明 描述了视觉、音频和认知挑战中的长期障碍。评估键盘导航、屏幕阅读器标签、焦点管理、对比度、本地化、移动布局、挑战持续时间和其他验证途径的可用性。用真实的辅助技术进行测试，而不是仅仅依赖于供应商声明。
隐私审核应映射提供者接收的数据、为何需要这些数据、在哪里处理、保留、子处理器、用户通知和合同控制。正确的结论取决于组织的管辖权和部署。避免将隐私简化为口号或假设不可见的挑战不会产生数据成本。
操作比较
运营团队应比较可观察性和故障处理与挑战外观。
审核仪表盘、密钥轮换、主机名限制、环境分离、审计日志、分析、服务限制、支持和事件程序。将验证错误单独跟踪，与低风险得分和用户放弃的挑战分开。已解决的令牌骤减可能来自内容安全政策、脚本阻止、过期配置或前端发布。
该 OWASP机器人管理指南 建议深度防御。CAPTCHA 应位于特定端点速率控制的后面，并且与身份验证、授权、欺诈检测和滥用监控并列。如果提供者不可用，请明确决定每个操作是失败封闭、排队还是提供另一种验证方法。
如何选择或迁移
在真实保护流中，通过合适的试点选择 reCAPTCHA 或 hCaptcha。
清点每个小部件、站点密钥、秘密、主机名、移动客户端、内容安全政策规则、后端调用、分析事件和支持文章。通过适配器实现新提供者，使用单独的测试凭证，并比较完成率、误拒率、延迟、滥用、可访问性和支持负荷。保留回滚路径，直到新流程稳定。
对于授权的公共数据工作，遇到任一服务意味着该站点正在应用访问决策。优先选择文档化的 API 或合作伙伴渠道，将流量保持在协议范围内，并获得重复收集的权限。选定 CAPTCHA 上下文的无痕支持不覆盖目标的规则。
快速比较
以下区分有助于将概念放置在操作工作流程中，而不会将不同的控制合并为一个标签。
| 维度 | 意思 | 典型使用 |
|---|---|---|
| 客户端令牌 | g-recaptcha-response 或回调结果 | h-captcha-response 或回调结果 |
| 服务器验证 | Google Siteverify POST | hCaptcha Siteverify 表单 POST |
| 主要模式 | 交互式 v2 和基于分数的 v3 | 小部件和基于风险的服务级别 |
| 迁移重点 | 脚本、密钥、操作、分数策略 | 脚本、容器、密钥、响应映射 |
实际审核检查表
可靠的实施首先要准确命名受保护或收集的表面。记录 URL 或端点、预期用户操作、相关数据字段、管理条款、预期客户端和可以批准访问的所有者。然后定义可能改变决策的证据。这防止模糊的标签成为广泛收集或永久阻止的借口。
每当浏览器发布、安全政策、数据源、模式或商业目的发生变化时，审核 recaptcha 和 hcaptcha。小的定期样本比大的无控制探测更具信息性：将预期结果与观察结果进行比较，分类差异，并将其路由到可以更正源或政策的所有者。保留普通访问、模糊边缘案例、可访问性场景和明确失败的版本测试用例。淘汰不再影响决策的字段和规则。这种节奏将一次性定义变成可审计、可解释和可改进的操作控制，而无需收集超出工作流程所需的数据。
- 确认目的。 将每个信号和字段与文档化的安全性、兼容性、发布或数据质量需求联系起来。
- 一次改变一个变量。 受控比较产生比许多同时配置更好的解释。
- 衡量用户成本。 跟踪虚假拒绝、放弃、支持需求、延迟和可访问性影响，并与安全结果并列。
- 保留证据轨迹。 保留最少的日志、源 URL、模式版本和决策类别，而不收集无关的个人数据。
- 提供审核。 受影响的用户、合作伙伴和批准的收集者需要一条途径纠正错误的分类。
结论
当定义、证据、决策和限制保持分离时，reCAPTCHA 与 hCaptcha 最易于理解。该概念描述了一个可观察的技术机制或数据模型；它很少能单独证明身份、意图、质量或权限。良好的实现使用最小必要信号，在上下文中验证它们、监控错误，并保持清晰的人类审核路径。
对于网络数据工作，优先使用官方 API 和导出，仅收集声明目的所需的公共信息，并在扩展之前设计稳定的模式。当浏览器渲染或托管检索合法必要时，在批准的范围内使用无痕方法，并保持可重现的工作流程。
准备构建受控数据工作流程吗？
从定义的范围、已验证的字段、保守的流量和与技术表面匹配的无痕产品开始。
免费开始 →常见问题
reCAPTCHA 和 hCaptcha 是完全可替换的吗？
不完全是。它们的高级流程相似，但脚本、HTML 类、字段名称、端点、响应字段、仪表板和政策选项不同。迁移需要前端、后端、安全政策、测试和监控的变更。
两者都需要服务器端验证吗？
是的。客户端令牌是不足够的。应用程序后端必须将令牌和秘密发送到正确的验证端点，并在接受受保护操作之前评估返回的结果。
哪个服务更具可访问性？
可访问性取决于选择的模式、配置、页面实现、用户人群和可用替代方案。在完整流程中测试键盘、屏幕阅读器、低视力、认知、移动和本地化场景。
一个CAPTCHA阈值能保护每一个端点吗？
不可以。登录、密码恢复、评论、结账和公开搜索都有不同的滥用风险和误报成本。根据每个操作调整策略，并随时间审查结果。