之前在广州城中村住了一段时间，也是房东不让拉网线，但是房东自己的网（ 50 块一个月）延迟高，网速慢，用了一个月之后实在忍不了了。我发现周围的 WIFI 信号特别多，后来就买了一个大功率网卡+定向天线，然后抓握手包跑弱口令，后来发现用万能 WIFI 可以直接获取密码。大概蹭了半年的网，回想起这段经历真是让人感慨。

数据权限一般直接穿透到持久层了，一般的做法是直接给每张表加额外的字段，辅以各种框架的拦截器修改 SQL 来实现的。

当然可以使用一张独立的表来跟踪所有的数据行，无论如何，都会引入额外的复杂性。想想操作系统是如何确定当前用户拥有某一个文件的读写权限呢？类似的，你也需要一种像文件系统的东西来支撑。

所以如果不是所有的数据都有这种数据权限的需求的话，直接按照最简单的来做，也就是针对这些有需要的地方，做专门的代码处理逻辑，理解需求真正想要的是什么。

如果你想直接通过 SQL 来进行匹配，可以使用正则表达式，取决于数据库支持的函数和运算符。不过看来这种元数据不会太多，因此全表扫描也是可以接受的。

可以看一下 Spring 是如何匹配的： https://github.com/spring-projects/spring-framework/blob/main/spring-core/src/main/java/org/springframework/util/AntPathMatcher.java

送人的话，山尔堂的银骏眉，或者他们家的清风红韵金骏眉，价格一两百块一两吧。

悲观锁：

在一个事务内，查询余额使用 SELECT .. FOR UPDATE 获取锁，这样其他事务既无法读取，也无法写入，但是要注意死锁的情况，顺序编排要一致。

乐观锁：

在一个事务内，更新余额使用 UPDATE account SET ..., version = @version + 1 WHERE id = @id AND version = @version ，这样更新失败的话返回的影响行数为 0 ，可以凭此判断是否成功。

如果你的 AccessToken 不是 Stateless 的（意味着每次都要读取状态，校验 AccessToken 的合法性，判断这个 AccessToken 是否已经被撤销，或者是否已经被替换），那么 RefreshToken 就没有太大的意义。

如果你的 AccessToken 不需要读取状态（无论是数据库或者缓存），仅凭 Token 本身的签名信息就能确定它的合法性（如 JWT ），那么 RefreshToken 的存在就相当于有了一个检查点，可以在检查点确认是否还可以续签。

因此 AccessToken 的有效期应当尽量设置短一点，通过 AccessToken 访问，只要通过签名校验合法即可通行，无序读取额外的状态来进一步确认是否撤销，当 AccessToken 过期以后再通过 RefreshToken 读取额外的状态（数据库 /缓存）确认是否继续签发。

越灵活的系统就越复杂，到一定程度实际上也是在进行编程的工作，只是过去是写代码，现在是另外一种形式，至于效率高低就仁者见仁了。

抽象程度越具体化，则它的应用范围则越窄，而高度抽象的系统本身也不容易使用，需要有一定的专业知识和使用经验。作为应用层来讲，当然可以使用已经定义好的简单抽象 /组件，而这些简单抽象来自于更高层面的抽象，所以为了解决复杂性，仍然存在层次，层次越高（封装得越多），则要求更低，使用门槛自然越低。

容器化的目的是什么？更新频繁么？数据库这种软件要的就是稳定性，很少有频繁操作吧，那么容器话的目的是为了安装省事么？

@ArmstrongLiu
1 、前端 Bcrypt 是可能的，我们需要的就是把“慢”这个过程放到客户端内，代码细节可以看一下我刚创建的这个测试，需要一个固定的盐值： https://jsfiddle.net/4zdw1jab/

2 、不使用明文不仅仅只是说为了传输上的考虑，明文就是“烫手山芋”，只要生成摘要的过程是安全可靠的，其实我们根本就不需要明文。其他的顾虑包括但不限于意外的日志输出或者其他的安全漏洞，所以彻底的做法就是后端根本就不接收明文。当然这一条只是作为一个建议，如果手动模拟注册请求给后端接口发送的就是明文，那么当然也可以模拟登录用之前的明文，关于这种“非法”注册的用户，当然也就排除在正常的产品流程之外了。

登录其实就是认证，认证与授权是两个相对独立的过程。

认证解决的问题：你是谁？一般只是简单的通过标识（用户名）和凭证（密码）来确定身份。确定身份以后，认证系统一般会发放一个 Token （令牌）或者直接绑定身份信息并关联当前的 sessionid （会话，通过 cookie 传递）。

授权解决的问题：在已认证的情况下，也就是我知道你是谁的情况下，你能做什么？

关于密码：不要使用明文，后端也不要接收明文（固然有 TLS ），前端可以使用 BCrypt 慢哈希生成密码摘要，不要在后端使用慢哈希。后端生成（注册）/获取（登录）动态盐值，与前端发过来的摘要结合再次哈希一遍得到最终的摘要信息。

关于 JWT：JWT 只是作为令牌的一种承载形式，它不可伪造，不可篡改，表达了签发此令牌的真实意图，但是不要将敏感信息放进去。好处固然有，例如完全可以在不跟签发者通讯的情况下对其进行验证（签名以及有效期），但是涉及到撤销的情况下，就必须记录每一个令牌的状态（ jti 是每一个令牌的 ID ），可以建立令牌黑名单机制，虽然丧失了完全的无状态好处，但是验证这个比较轻量级。

我想说的就是可以根据场景结合混合使用不同的技术，关于安全这一块，不要自己去发明东西，大胆的使用经过时间检验的通用方法，具体如何实现只是细节问题（比如框架，亦或是自己手写），但是在流程上，概念上一定要有清晰的认知。

刚刚看到跟我这个同型号的 Sage878 ，现在只要 3984 包邮包税： https://www.smzdm.com/p/42912826/

@qwe520liao 不好意思看错了，我还以为直接使用呢，要自己做平台的话就不合适了

自建 confluence

@oieoieoie 铂富 878 ，某东国际到手 4300

@fuxkcsdn https://www.mysmth.net/nForum/#!article/WorkLife/2731643 是这个公司吗？

我用的是 LV273HUPR ，目前系统是 Big Sur ，也就是说升级完以后必定会出现这个问题吗？

DDD 里面确实有一系列指导程序编码的战术设计，但更多的是强调概念统一，减少翻译的层数，使得讨论的问题跟编码设计都能够一一对应上。

举个例子，就像一个游戏，五六个人站成一列，最后的那个人在前面那个人的背上写字，然后依次传递信息到第一个人上。人数越多，那么错误的概率也就越大。如果确实有人连字都不认识的话，那么即便只有两三个人也会导致这个问题。

DDD 就是告诉你，在一个建模的框架范围内，大家都具备这些框架的基础理论知识，然后基于这些建模框架构建出一套人人都能理解的模型，使其高度契合产品的业务需求，避免产生概念 /模型不一致的情况。