一、用户系统

目录

1、数据表设计

2、用户认证

3、用户的信息管理


1、数据表设计

一般设计用户表会设计很多字段,虽然有些不会用到,但还是要设计进去

(1)基础认证字段

|----------|----------|-------|-------|--------|-------|----------|---|
| username | password | email | phone | avatar | roles | isActive | |
| 用户名 | 密码 | 邮件 | 电话 | 头像 | 角色 | 账号激活 | |

(2)用户个人信息

|----------|--------|------------|--------|-----------|
| realName | gender | isVerified | idCard | birthDate |
| 真实姓名 | 性别 | 是否实名认证 | 身份证号 | 出生年月日 |

(3)vip相关

|-------|---------------|
| isVip | vipExpireTime |
| 是否会员 | 会员过期时间 |

(4)配额相关(业务部分)

假如是个做ppt的,那就会有:虚拟币余额,免费剩余次数等

(5)用户行为追踪

|---------------|-------------------|
| lastLoginTime | lastLoginLocation |
| 最近登录时间 | 最近登录地点 |

(6)微信相关

|----------|-----------|------------|----------------|--------------|---------------|-----------------|
| wechatid | openid | unionid | wechatNickname | wechatAvatar | isWechatBound | wechatBoundTime |
| 最初微信标识 | 唯一标识(小程序) | 唯一标识(开放平台) | 微信昵称 | 微信头像 | 是否绑定微信 | 微信绑定时间 |

2、用户认证

(1)JWT

1.用户输入账号密码post请求,

2.后端根据账号密码查数据库将用户基本信息拿出(没有密码)

3.后端根据基本信息+jwt密钥+jwt算法生成带签token,就是类似: token类型.基本信息.验签字符串 这样的一长串字符串

4.前端post的结果会得到这个token存到本地,后续功能必须携带

5.前端下次请求携带token

6.后端处理请求前先处理这个token,用第一次同样的方式,token上的基本信息+后端jwt密钥+jwt算法,看生出来的验签字符和第一次一样不,不一样说明被改过,防止黑客将自己的普通账号改成管理员。然后后续的请求就是正常请求了,就用用户基本的信息查询数据

总结:就是之前的是用密码,来一次验证一次密码

JWT就是只验证一次密码,但是会用规则生成一个token后续就是验证token

缺点就是可能黑客会截取你本地存到token,然后用你的身份发请求,但是它好在不会修改用户身份,而且现在用https,一般也不好获取本地token

3、用户的信息管理

就是用户的个人信息的修改啊,获取,删除啥的

还有用户在该系统上的业务功能的数据,比如假如是做ppt的,那就有你用于业务的虚拟币啊,使用次数啊啥的

具体的做ppt的功能是能外一个模块,但是数据是个人数据

相关推荐
Csvn35 分钟前
安装、升级与目录结构
后端·nginx
皮皮林5511 小时前
万能通用!权限系统就该这么设计
后端
GoAI2 小时前
DeepSeek Harness Memory (一)主流记忆插件总结
后端·算法·面试
橙子家3 小时前
RESTful 接口:它并非标准或协议,而是一种【架构风格】
后端
小兔子4 小时前
dict.get 的默认值每次都会求值,哪怕键本来就在
后端
斯维赤4 小时前
限流、熔断、降级,你真的分得清吗?
java·后端·架构
肌肉娃子4 小时前
红队攻防测试报告 — wechat-e.cfd
后端
陈随易4 小时前
Cmder 停更 17 个月,2.0 支持 Windows Terminal
前端·后端·程序员
海螺_AIHCC4 小时前
SSE 流式返回中文变问号,问题不在编码
后端
panbook4 小时前
从零实现一个时序数据库(一):用 Rust、Arrow 和 Parquet 跑通写入与 SQL 查询
后端