【问题标题】:Trying to understand how recaptcha works step by step尝试逐步了解 recaptcha 的工作原理
【发布时间】:2022-12-14 22:09:28
【问题描述】:

这是我目前对recaptcha的理解(使用v2 invisible)

  • 我们将 api.js 脚本加载到我们的网站上
  • 我们给按钮添加数据属性
  • 用户点击按钮
  • api.js 脚本中某处的侦听器会触发,因为它正在侦听具有这些数据属性的标签上的事件
  • 这就是它变得模糊的地方,我开始猜测:
  • api.js 从用户的 cookie 中收集浏览信息以及有关他们如何与网站交互的信息。基于此,它确定您成为机器人的可能性有多大,如果您低于某个阈值,它会给您一个测试。您是否通过测试然后会进一步计入您的分数,所有这些都会被编码到一个令牌中,我们在我们在按钮的数据属性上指定的回调中接收到该令牌。
  • 我们将此令牌与表单的其余部分一起传递到后端
  • 我们从后端向 Google 发出 API 请求,以将令牌转换为有关用户是通过还是失败的可用信息。

在这一点上,我对为什么这不仅仅是 api.js 脚本首先返回的内容感到困惑。这一步是否只是为了给 Recaptcha 信息以进一步改进它而存在的?我只是不明白为什么这一步在这里,除非我误解了这个过程的早期发生的事情。我是不是弄错了这些步骤?谢谢。

【问题讨论】:

    标签: recaptcha


    【解决方案1】:

    验证码的全部意义在于你服务器(而不是浏览器中的客户端)可以在与您的应用程序交互时验证它收到的 (HTTP) 请求是由真人的操作生成的。

    这就是为什么您的客户端向您的服务器发送一个 recaptcha 令牌,而您的后端就此令牌向验证码提供者咨询并接收有关原始客户端的可信信息的原因。在这种情况下,您的服务器不信任客户端,因此它只从客户端接收到一个令牌。然后它与受信任的验证码提供者进行服务器到服务器通信,并验证它从客户端收到的令牌是否有效以及它背后的用户是否合法。

    如果您的客户端将来自验证码提供程序的原始响应发送到您的后端服务器,您的服务器将无法知道这是来自验证码提供程序的合法响应,还是来自客户端的虚假响应。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-02-20
      相关资源
      最近更新 更多