共 3 篇相关文章
这篇讲的是多用户Web应用中一个经典问题：表单重复提交。从用户误点两次按钮、刷新页面，到使用浏览器前进/后退，甚至网络层的重复请求，都可能导致同一数据被多次处理，带来数据不一致或资源浪费。 文章梳理了四种常见的应对策略。前端层面，可以暂时禁用提交按钮，但这依赖客户端JavaScript，不够稳健。更推荐的做法是采用Post/Redirect/Get模式——提交后立即重定向到结果页，从根本上避免刷新或回退带来的重复提交。后端控制上，可以在session中为每次生成的表单嵌入一个一次性令牌，服务器处理时立即核验并删除，这是一种结合了安全考虑的有效方案。最后，从数据源头兜底，在数据库层面设置唯一约束或索引，确保即使重复数据到达也能被拦截。 这些方法各有侧重，从用户交互、请求流转、会话状态到数据存储形成了多层次的防御。实际开发中，往往会根据应用的安全要求和复杂度，选择组合使用这些策略。
这篇讲的是OAuth1.0协议本身。作为OAuth标准的“开山之作”，这份演讲稿深入剖析了它如何解决一个核心痛点：让第三方应用在不获取用户密码的前提下，安全地获取对用户资源的有限访问权限。 内容从协议的诞生背景切入，详细拆解了其“委托授权”的核心设计原则。最值得玩味的是它的流程设计，尤其是那个要求所有请求都必须携带数字签名的机制。这个签名过程虽然极大地增强了安全性，有效防止了请求被篡改和重放攻击，但也导致了实现起来相当繁琐，客户端和服务端都需要处理复杂的签名逻辑。 因此，讲解中自然也会将它与更主流的OAuth2.0进行对比。一个关键区别在于，OAuth1.0强制使用签名，而OAuth2.0则完全依赖TLS（HTTPS）来保证传输安全，从而大大简化了流程。这使得OAuth2.0在移动和Web应用中更为流行，但OAuth1.0那种对客户端密钥和请求签名的严格校验，在某些对安全性要求极高、系统架构相对传统的场景下，依然有其不可替代的价值。
作者在等待世界杯开幕的间隙，阅读了Cassandra中关于分布式哈希表（DHT）的核心源码，这篇笔记便由此而来。他从生产系统运维的实际关切切入，探讨了Cassandra中数据如何通过Token机制被可靠且均匀地分布到集群的各个节点上。 文章深入Cassandra的源码层面，解析了Token的生成与分配逻辑。其核心思路是为每个节点分配一个唯一的Token值（通常是一个巨大的整数），这个值定义了该节点在环形数据空间中的位置。所有数据也通过哈希函数映射为Token值，并顺时针查找到达的第一个节点进行存储，由此构成了“一致性哈希”的基础。作者在代码中特别关注了Token的计算算法与节点加入、退出时的数据迁移过程，揭示了系统如何通过巧妙的设计，在保证数据高可用的同时，尽可能实现负载的均衡。 这不仅仅是理论推导，更是对生产环境中数据分布策略的细致考量。理解Token机制，就是理解Cassandra如何在大规模集群中实现优雅扩展和故障容忍的根基。
