调用Schoology API users/me接口返回重复nonce错误如何解决

通过two-legged鉴权模式调用users/me接口获取用户UID时，返回如下错误属于典型的防重放校验拦截：

Duplicate timestamp/nonce combination, possible replay attack. Request rejected.

该报错的核心触发逻辑是：服务端会记录所有有效请求携带的时间戳（timestamp）+随机串（nonce）组合，一旦检测到相同组合重复提交，就会直接拒绝请求，避免请求被截获后重放伪造操作。靠暴力重复请求碰运气的方式没有实用价值，可按以下规则彻底修复：

• 每次生成请求鉴权参数时，必须重新生成全新的nonce值，绝对不能复用历史请求（包括之前失败的请求）的nonce。nonce推荐使用16位以上的加密安全随机串，比如去掉横杠的UUID v4、系统加密随机数接口生成的十六进制串，不要用自增序列、短位随机数这类容易出现碰撞的生成逻辑。
• timestamp参数必须取请求发起那一刻的当前Unix时间值（精度匹配接口要求的秒级/毫秒级），不要把时间戳写死在代码常量里，也不要提前批量生成鉴权参数存储待用。如果运行环境的本地时间和API服务端时间差超过3-5分钟，也可能触发校验异常，必要时需要先做时间校准。
• 重试请求必须刷新全部鉴权参数：很多人遇到这个问题的核心原因是重试逻辑偷懒，第一次请求签名算错或者超时后，直接拿着之前算好的带固定timestamp/nonce的鉴权头反复发。实际上哪怕第一次请求没成功，只要这组timestamp/nonce被服务端接收到过，就会被加入去重列表，后续再发相同参数必然被拦截。重试时必须重新生成timestamp和nonce，再基于新参数重新计算签名后发起请求。
• 不要依赖暴力重试的野路子：这种方式本质是赌新生成的参数刚好没和历史记录撞车，成功率极低，还很容易触发接口的限流策略，导致应用密钥、出口IP被封禁，完全无法在生产环境使用。

注：绝大多数该类报错都是三个低级问题导致的：调试时写死了timestamp和nonce、封装的SDK缓存了鉴权参数没有每次重新生成、重试逻辑没有刷新鉴权参数，排查时优先检查这三点即可。

内容的提问来源于stack exchange，提问作者John Exterkamp