1. 前端整合后端发短信接口
2. 注册功能
后端提供注册接口,接受前端传入的参数,创建新的用户对象,保存到数据库。
-
接口设计:
-
实现步骤:
- 手机号码唯一性校验(后端一定要再次校验手机号唯一性):基于手机号查询是否已经存在该手机号,如果存在则返回异常。
- 从redis中获取验证码,与前端传入的验证码进行一致性校验,如果不一致则抛出异常
- 删除redis中的验证码
- 创建用户对象,填入参数并补充其它默认值
- 对密码进行加密
- 保存用户对象到数据库
-
编码实现:
-
controller
-
service
手机号码唯一性校验:
注意:
密码加密:使用md5加盐值进行加密
Md5Utils.getMD5(password + phone);
phone即充当盐,这是一个简单的实例,实际业务中可以散列,或者按照一定的规律进行增加复杂度,即密码安全性。整体业务:
统一异常处理:
统一异常处理后的核心业务:
细节:
对于redis中的key,由于其可能具有复用性,故可将其抽取成常量。
-
3. 登录实现
HTTP无状:不会记录之前请求的信息,每次请求都是独立的,请求之间不会相互影响。
- Session登录
收到用户名密码,后端进行校验,后端校验通过后,将用户存入Session,再访问其他接口时,判断Session中是否有对象,如果有,说明已经登录,反之未登录。
加入Session后,HTTP协议还是无状态的吗?
Session的原理:每个浏览器地依靠此访问Tomcat服务器的时候,会创建一个Session对象,并且生成一个唯一的SessionID,将SessionID返回给浏览器,浏览器将其存入Cookie中,之后该浏览器的每次访问都会携带SessionID,因此,Tomcat可以根据SessionID来知道谁是谁。**Tomcat服务变成了有状态的服务。**缺点是无法做横向扩展。
- 基于Token+Redis的登录方式
前端传递用户名密码,后端校验通过以后,生成一盒token作为key,用户对象作为value存入Redis,并且将token返回给浏览器,浏览器将其存储在本地,之后每次发起请求时,将token携带在请求头中,基于token从Redis中获取,判断token是否有效。
与Session登录的区别:将原先存储在Session的数据,存储在Redis中了,实现了分布式Session的共享。
Session其实可以理解为一个抽象的概念,即浏览器与服务器的会话。
这个时候,Tomcat仍然是无状态的服务。
- 新的登录方案
既能实现Session访问的高效,又能不用考虑数据共享问题,保证服务/协议的无状态特性。
方案:前端传递用户名密码给后端,后端校验通过后,生成一个唯一的token,以及将用户基础信息返回给前端,前端保存下来,之后只要用户传了token,就认为用户有登录。问题:token可能被伪造,无法确认token的有效性。
只要能够实现后端生成的token,客户端用户收到后,无法改造,而且后端还有办法验证该token有效,且可以实现针对token实现过期机制,就可以采用这样的方案。 - 基于JWT登录
JWT(JSON Web Tokens)是一种开放标准(RFC 7519),用于在两方之间安全地传输信息作为JSON对象。
这种信息传输可以被验证和信任,因为它是数字签名的。JWTs常用于身份验证和信息交换,特别是在Web应用程序中。
JWT的组成
一个JWT通常由三部分组成,分别是头部(Header)、有效载荷(Payload)和签名(Signature)。
1. 头部(Header):
- 包含了用于处理令牌的类型(typ,通常是JWT)和签名或加密算法(alg,如HMAC SHA256或RSA)。
2. 有效载荷(Payload):
- 包含所谓的“声明”(Claims),这些声明是关于实体(通常是用户)和其他数据的声明。
- 有三种类型的声明:注册声明(如iss发行人、exp过期时间)、公共声明(通常自定义,如用户ID和用户名)和私有声明(双方之间协商的信息)。
3. 签名(Signature):
- 用于验证消息在传输过程中未被篡改,并且,对于使用秘密密钥签名的令牌,可以验证发送者的身份。
- 签名是使用头部指定的算法以及服务器存储的秘密(对于HMAC算法)或私钥(对于RSA和ECDSA)来生成的。
JWT的使用
在身份验证过程中,当用户成功登录后,服务器会创建一个JWT,并将其发送回用户。然后用户在随后的请求中将此令牌发送回服务器,以验证其身份并访问受保护的资源。
JWT的优势
- 无状态和可扩展性:JWT不需要在服务器上存储会话信息,因为令牌本身包含了所有必要的信息。这对于构建可扩展的应用程序特别有用。
- 跨语言支持:由于基于JSON格式,JWT可以被任何支持JSON的语言使用。
- 安全性:数字签名确保了在传输过程中令牌未被篡改。
注意事项
- JWT不应包含敏感数据,因为其有效载荷可以被解码(即使是有签名的,也只是防篡改,而不是加密)。
- 适当的安全措施应该用于处理JWT,特别是在使用公开/私有密钥对的情况下。
JWT因其简洁性和功能性,在现代Web应用程序中被广泛使用,特别是在实现无状态的API和单点登录(SSO)等场景中。
-
编码:
controller:
service: