reCAPTCHA v3重复令牌验证异常问题排查求助

1. 验证Google reCAPTCHA v3的令牌复用处理逻辑 #

• 核对成功请求的时间戳，确认是否集中在令牌生成后的2分钟有效期内（reCAPTCHA v3令牌默认有效期），且请求间隔极短。Google的siteverify接口可能对极短时间内的重复令牌调用（如毫秒级）视为同一操作的重试，暂时允许通过。
• 提取成功请求对应的siteverify完整响应，检查是否存在error-codes字段，对比失败请求的响应差异，确认Google返回的验证依据是否符合预期。

2. 排查API验证逻辑的实现漏洞 #

• 检查代码中对siteverify响应的解析逻辑：是否存在拼写错误（如将success写成sucess）、JSON解析失败时默认走“验证通过”分支的情况？
• 确认是否有本地缓存验证结果的逻辑：若API节点本地缓存了令牌的验证状态，第一次验证成功后，后续请求直接复用缓存结果而非重新调用siteverify，会导致部分请求绕过重复验证。
• 检查异常捕获逻辑：是否在调用siteverify出现网络异常时，错误地将异常分支判定为验证通过？

3. 负载均衡与API节点的状态排查 #

• 查看负载均衡的会话粘滞策略：若开启了会话绑定，同一用户的请求会持续发往同一API节点，该节点若缓存了验证结果，会导致该用户的所有循环请求都通过验证，对应到测试中的部分请求成功。
• 检查API节点的时钟同步情况：若节点之间时钟偏差过大，且代码中额外添加了令牌有效期的本地校验，可能导致部分节点误判令牌仍在有效期内。
• 若使用了分布式缓存（如Redis）存储验证结果，检查缓存逻辑是否正确标记了令牌已被使用，是否存在缓存更新不及时或失效时间设置过长的问题。

4. 核对siteverify请求参数的正确性 #

• 确认API调用siteverify时是否传递了remoteip参数：若未传递用户真实IP，Google的验证逻辑会更宽松；若传递的是负载均衡节点的IP而非用户真实IP，可能影响重复令牌的判定规则。
• 检查所有请求中使用的reCAPTCHA密钥是否一致，是否存在部分节点配置错误密钥的情况。

5. 压力测试场景的细节验证 #

• 确认JMeter中是否存在请求并发控制的问题：是否有部分请求在令牌生成后的极短时间内同时发送，导致Google的反滥用机制未及时标记令牌已使用？
• 检查测试过程中是否有令牌被意外刷新的情况，比如JMeter的配置是否存在动态获取令牌的逻辑，导致部分请求使用了新生成的有效令牌。

内容的提问来源于stack exchange，提问作者Mikhail Korolev