合集-nest.js后端开发
双Token实现无感刷新登录状态
摘要：基于access_token和refresh_token实现无感刷新登录状态 双token原理 这是登录认证的流程: 验证通过之后，将用户信息放到jwt中。 访问接口的时候带上jwt，在Guard里取出来判断是否有效，jwt有效的话才能继续访问： 这种方式有个问题： jwt是有有效期的，我们设置的是
RBAC权限控制 （Role Based Access Control）
摘要：ACL和RBAC对比 之前的ACL权限控制是直接给用户分配权限的。 而RBAC是这样的： RBAC是先分开角色，然后把角色分给指定的用户 通过在用户和权限之间多加一层“角色”来做权限管理 给角色分配权限，然后给用户分配角色 这样有什么好处呢？ 比如说： 管理员有 a、b、c 3个权限，而张三李四王五
基于ACL (Access Control List)实现权限控制
摘要：ACL是直接给用户分配权限： 比如用户1有权限A、B、C，用户二有权限A，用户3有权限A、B。 这种记录每个用户有什么权限的方式,叫做访问控制表 (Access control List); 用户和权限是多对多的关系，存储这种关系需要用户表、角色表、用户-角色的中间表。 我们来实践一下： 在数据库中
Dockerfile基础
摘要：一个基本的dockerfile: FROM node:latest WORKDIR /app COPY . . RUN npm config set registry https://registry.npmmirror.com/ RUN npm install -g http-server EXP
PM2相关命令
摘要：超过200M内存自动重启： pm2 start xxx --max-memory-restart 200M 从2s开始每3s重启一次： pm2 start xxx --cron-restart "2/3 * * * * *" 当文件内容改变自动重启 pm2 start xxx --watch 不自动
web中两种登录状态保存方式：JWT和Session
摘要：由于http是无状态的，也就是说上一次请求和下一次请求之间没有任何关联。 那如何实现登录状态的保存呢？ 一般使用两种方案： 服务端存储的session + cookie的方案 客户端存储的jwt token的方案 但是这两种方式都有各自的缺点。 服务端存储的session + cookie 给htt
nest.js中不同环境的配置读取
摘要：node中不同环境的配置读取 在node中最常用的是.env格式的配置文件，他有一个专门的npm包 dotenv： 我们来创建一个node项目试一下： 进入这个目录，安装dotenv: npm install dotenv 然后新建一个.env配置文件： aaa=1 bbb=2 新建index.js
nginx灰度系统
摘要：灰度系统简介 一般软件开发都不是最终版本交付，而是有一个版本接着一个版本的迭代 新版本上线之前都会经过测试，但就算这样，也不能保证上线没有问题 所以，一般上线新版本代码都是通过灰度系统 灰度系统可以将流量划分成多份，一份走新版本代码，一份走老版本代码 而且灰度系统支持设置流量的比例，比如可以把走新版
