2019-12-02工作中遇到非crud的需求我就会想尽一切办法让他通用，基本需求分析和需求设计的时间占用百分之五十，开发和重构到自认为最优占用百分之五十。比如最简单的验证码功能，几乎每个项目都有，我就封装一套验证码服务，主要功能有你在配置文件里配置好需要被验证码拦截的路径，这里还要考虑到通配符，空格等等细节和可扩展的点，内置图片验证码，极验证，手机验证以及自定义验证码等等，总之我认为如果有机会遇到非crud的需求，一定要好好珍惜，好好把握，把他打造成属于自己的产品，这样会让自己下意识的去想尽一切办法把他做到最优，亲儿子一样的待遇，再也不会无脑cv，连变量名可能都要认真的重构一两遍😹😹😹 10 121
2019-12-02一句话：使用进化算法的思想，提出一个MVP（最小可行性产品），逐步迭代改进。
拿到这个需求，假设我们不了解接口鉴权，需求又不明确，我会我自己如下问题：
1.什么叫接口鉴权？搞清基本概念
2.接口鉴权最佳实践是什么？技术调研
3.appid和secret key从哪里来？用户自己申请还是我们授权？用户申请是以什么方式申请（网页还是邮件？申请的网页有人做了么？）追问下去。
4.appid secretkey存储在什么地方呢？数据存储
5.用户如何使用？需要为用户提供接口鉴权使用手册和文档，及示例代码。写用户手册，文档。
6.这个功能如何测试？提前想好如何测试
7.接口鉴权功能何时上线？估计工期
8.鉴权成功或失败返回码和信息定义？约定返回结果
关于防止重放攻击：请求参数中还可以加入nonce（随机正整数），两次请求的nonce不能重复，timestamp和nonce结合进一步防止重放攻击。展开 14 112
2019-12-03OAuth 2.0 + 网关（如Zuul）+ 认证中心 + AOP可以实现。
极客时间《微服务架构实战160讲》里介绍了OAuth 2.0企业级的解决方案，小争哥的方案适合快速落地。
实际业务中如果安全等级没这么高，直接生成Token鉴权就可以。通过业务模型规避风险：
1. 充值类业务，就算对方篡改接口，最终结果可以通调用证金融机构的接口验证是否有效，不会给公司带来损失。
2. 如果安全等级非常高，比如提现、转账可以通过发送手机短信，确保是本人操作。
3. 如果是商品信息查询类接口，防止第三方爬取数据，可以在调用一定次数后加入”人机验证“（输入图片识别码、拼图）。
4. 根据IP限制访问次数。
5. 服务器间调用可以绑定mac地址、IP。
6. 服务器、客户端通过架设私有VPN进行通信，将安全问题转移到VPN上，降低业务复杂度的同时还可以避免加解密带来的性能损耗，提升性能。
7. 调用接口时通过付费方式（如实名认证、银行四要素验证这些调用一次都是要收费的），防止恶意调用。
8. 通过独立加密硬件（如U盾）+ 独立密码验证器（Google验证器）+ 语音识别 + 面部识别（刷脸支付） + 指纹 + 多人同时输入动态秘钥（核打击时发射程序）。
9. 安全性会降低系统性能适可而止。
极客时间《左耳听风》专栏中介绍了亚马逊在设计开发微服务时，就已经做好了随时对外网开放的准备，由于没有阅读完整个专栏，不知道后面有没有详细介绍。展开 1 53
2019-12-08光拼url是不够的，只能覆盖如HTTP GET一类参数在url中的请求，对于如POST和PUT一类的请求，因为参数通常在body中，就没有参与token的生成。又因为这样的方案存在允许重放请求的时间间隔，就可能导致的情况是中间人截获了请求，在允许重放的时间间隔内任意修改body中的参数后发送，让接口鉴权形同虚设作者回复: 嗯嗯，说的有道理~
18
2019-12-02还有个风险，如果调用方是app，那有可能app被反编译，然后加密算法就被第三方知道了 13 12
2019-12-02这个需求去年我就做过，给自己系统的对外接口开发一个鉴权的功能。因为之前了解过oauth2，当时就直接想到了oauth2鉴权来实现，就去学习了下，然后选择了“客户端模式”来实现，给各个应用分配appid和appsecrete，客户端拿appid和appsecrete请求有一定时效的token，应用拿到token后再跟appid和appsecrete一起来请求接口，服务端鉴权通过后即可调用。老师的例子是客户端定开始时间，我做的是服务端定开始时间。
不过当时分析的时候没有意识去一步步分析，就是一下子想起来就去做了，也没有去想着做什么优化，以后在遇到这种问题，应该多去分析，思考，才能让设计更优。 8 9
2019-12-02打卡
充血模型那两节还没完全理解，加油 3 9
2019-12-05老师好，感觉在鉴权这个例子中，无论客户端如何加密，攻击方的逻辑都是不变的。只需要截获请求，并不需要解析token.
如果能在token中加入客户端的特征变量，比如ip或者mac，服务端获取特征变量，然后和appid等一起生成token再比较。这样会更好。要不然总感觉在自欺欺人 2 8
2019-12-06https://github.com/murreIsCoding/auth
根据实战教程编写的，放到了github上 5
2019-12-02像今天的例子中，如果老板给我这样的需求，我第一反应就是去想怎么实现，用什么技术实现，有什么现成的框架，而不是去先思考「用户名密码登录验证」这最基础的第一步。刚开始脑子就一团浆糊，知道完成也是在便实现便理思路，这样浪费时间而且最后也没有自己完整的思路过程。
以后还是要先理清思路，理清需求再去考虑每一小需求实现的技术。 5
2019-12-02我看到过的最好的设计模式课 4
2019-12-02一般遇到这种需求不是特别明确的，先自己理解第一遍需求，有一个大概的思路，然后在和产品经理确认是不是这样。需求确认之前在按照争哥说的需求分析，对需求做任务分解，将需求分解成一个个小的任务点，每个小任务都是很容易执行的。就算开发过程中被打断了，也不要紧。任务分解的尽量小，这样重新回到开发状态也就越容易。 4
2019-12-04我觉的老师的方案也没有增加攻击方的试错成本吧，我每次截获调用接口的请求，获取你调用的URL，在这个过期时间内仍然可以非法调用微服务方的接口啊。做了这么多的加密，可是对于攻击方，我的攻击成本增加在哪里了呢？
请老师解答一下哈 1 3- 2019-12-02我主要是嵌入式软件开发的，这个鉴权功能基本理解了，但是前面的mvc，包括贫血和充血，还是挺不明白的，平时没有用过，理解有些困难，暂时先放放吧，等后面再回过来学习 3
- 2019-12-02我是做业务需求的：我们期望于产品画清楚流程图，表达好规则描述，
a.有些产品做的足够细致时，rd照着流程实现就好了。
b.有些产品表达的很粗糙，rd会按照自己的梳理，然后向产品要相关时刻的规则，最后rd再照着实现。
感觉针对一个具体业务需求时，貌似技术实现到底多么优雅取决于与之合作的产品，总觉得不对，但貌似又无能为力 3 
2019-12-061 推荐写markdown 进行描述
2 分析将做什么转为怎么做，并将怎么做拆解的足够小，单步可验。
3 过程是渐进的，逐步分解 2
2019-12-05防止重放攻击的方案在老师的基础做进一步的迭代设计:
1.要求客户端生成一个唯一的请求id，如以uuid方式
2.客户端在以sha等加密哈希方式生成token时，也将请求id加入其中
3.客户端也要将请求id作为参数传递到服务端，如果是rest api就是也要将请求id拼接到url参数中
4.服务端检查服务端的缓存中(可以是redis)是否有客户端传递的请求id，如果有，则判定为重放攻击，拒绝请求。如果没有，则将请求id放到缓存中同时设置在token失效的时间窗内缓存的请求id自动失效(如redis key的TTL)
这个实现思路是: 在时间窗内的重放攻击，以服务端在时间缓存了在时间窗内的所有请求id的形式来防护，而在时间窗外的重放攻击就是老师的方案中检查客户端传过来的时间(时间戳)和服务端当前时间(时间戳)相减的绝对值不能超过时间窗的长度来实现。另外，时间戳、请求id等都hash在了token
中，所有客户端是无法篡改的。
这个实现思路的缺点是: 改实现方案要求客户端的时间和服务端的时间之间的差距不能超过时间窗，如果时间窗设置为1分钟这种比较小的，则要求客户端时间和服务端时间不能超过1分钟，这个有点苛刻，比如客户端如app所在的手机的时间不准确了，但就差1分钟，将无法访问接口。如果时间窗设置过长，如30分钟，则要求服务端缓存中缓存最近30分钟的请求id，如果接口的访问并发挺大的话，缓存占用空间也将很大，需要评估。展开 2
2019-12-02打卡，依旧在理解贫血和充血模型 2
2019-12-05遵循合适原则、简单原则、演化原则三个原则，有助于做出最好的选择。在实际的项目中，我们要结合业务 、技术、成本三个方面综合考虑具体的方案。 1
2019-12-04Day10: 先设计，在完成核心功能试验，设计时要考虑以后可能的改动，要考虑最常用场景的性能优化，如果这个功能和已有功能有重叠，考虑进行重构，如果没有重叠但是有使用相同的数据，要考虑到是否有数据不一致的bug,设计时还要考虑到极端情况，最好先写出测试case。 1