王争《设计模式之美》学习笔记
案例介绍和难点剖析
- 文中作者以一个真实的开发案例，从基础的需求分析、职责划分、类的定义、交互、组装运行讲起，将最基础的面向对象分析、设计、编程的套路给你讲清楚，为后面学习设计原则、设计模式打好基础。
- 真实案例，给你的微服务增加接口调用鉴权功能。
需求不明确
- leader 给到的需求过于模糊、笼统，不够具体、细化，离落地到设计、编码还有一定的距离。
- 面向对象分析可以粗略地看成“需求分析”。
缺少锻炼
- 鉴权作为一个跟具体业务无关的功能，我们完全可以把它开发成一个独立的框架，集成到很多业务系统中。
- 开发这样通用的框架，对工程师的需求分析能力、设计能力、编码能力，甚至逻辑思维能力的要求，都是比较高的。
对案例进行需求分析
第一轮基础分析
设计通过AppID和密钥来认证。
第二轮分析优化
防止“重放攻击”，增加加密token验证。
第三轮分析优化
依然有“重放攻击”风险，引入时间戳作为随机变量。
第四轮分析优化
- 在允许时间范围内（比如1分钟），依然有攻击风险，这是一个攻防策略。
- 这里作者还提到了一下，多端多AppID要如何存储，设计时要留有扩展点，当更换存储时减少代码改动，多运用面向对象的编程思想。
- 我觉得作者这里就是讲一个需求分析，大家主要吸收的是一个分析的过程，一个思考的过程，如何循序渐进，拆解需求，完善设计，迭代优化。不用过分盯着这个具体案例还不够完善安全等。
最终确定需求
- 调用方进行接口请求的时候，将 URL、AppID、密码、时间戳拼接在一起，通过加密算法生成 token，并且将 token、AppID、时间戳拼接在 URL 中，一并发送到微服务端。
- 微服务端在接收到调用方的接口请求之后，从请求中拆解出 token、AppID、时间戳。
- 微服务端首先检查传递过来的时间戳跟当前时间，是否在token 失效时间窗口内。如果已经超过失效时间，那就算接口调用鉴权失败，拒绝接口调用请求。
- 如果 token 验证没有过期失效，微服务端再从自己的存储中，取出 AppID 对应的密码，通过同样的 token 生成算法，生成另外一个 token，与调用方传递过来的 token 进行匹配；如果一致，则鉴权成功，允许接口调用，否则就拒绝接口调用。
来源：CSDN
作者：linglongwunv
链接：https://blog.csdn.net/linglongwunv/article/details/103824533