有一点没想明白，如果针对客户端是 web 页面的情况，那么 nonce 的生成算法，就一般都是在 web 端的 js 代码中了。 这样相当于 nonce 的生成过程，仍然是对客户端暴露的，只要重放人有能力进行客户端 js 的分析与模拟运行，那不是 nonce 就失效了么？ nonce, 客户端, Web, 生成
一个 nonce 只能够请求一次，你抓到了 nonce 再一次请求是不可能成功的啊， 怎么可能进行重放攻击？ 你是不是混淆了 nonce ？ nonce 不是 token 啊 ， 不需要任何算法， 你自己手输入一个随机字符串也可以啊。没有人会对 nonce 校验，单纯的放一个列表里就行了。 一个算法就做一件事情，nonce 就只防止重放攻击，其他的安全措施需要用其他的算法，别混淆。
@LonnyWong 理解了。但这样也是假设在这个“别人”并没有对服务端客户端深度分析的情况下吧。如果这个“别人”是有心人，分析了这个 nonce 整体的交互和生成过程。那应该也是仍然可以实现重放的？ 又，如果要防用户的重复请求呢？尤其是查询类，没有类似金额控制类的情况呢。
@jinliming2 这意思是，nonce 是随着用户前一次请求，由服务器端返回客户端的，并在下一次请求中再带上服务端么？我看的理解还以为是都是客户端完全随机生成 uuid 或者带点 timestamp 之类的客户端算法生成？ 如果是服务器端生成，那对于分布式化的服务端，一是要搞个中心存储节点来存了吧？二是，这样会禁止掉在客户端开启多个 web 页面，并行操作的可能？
一般都是服务器返回的，你访问一下这个： https://acme-v02.api.letsencrypt.org/acme/new-nonce 返回的头有 replay-nonce ，每次都会变，正常情况下客户端是无法生成的。 那些能生成的，都是野路子。
@matepi nonce 是完全随机的，一次性的，知道怎么生成也没用。你说的别人分析交互过程，不是防重放，是防假冒，要用其他手段来解决。 防重复请求，一般在请求前生成一个唯一的 ID ，后台要根据这个 ID 去重，前端要确保同一个请求的 ID 相同且全局唯一。
