旅游项目day03

发布时间:2024年01月18日

1. 前端整合后端发短信接口

2. 注册功能

后端提供注册接口,接受前端传入的参数,创建新的用户对象,保存到数据库。

  • 接口设计:
    在这里插入图片描述

  • 实现步骤:

    1. 手机号码唯一性校验(后端一定要再次校验手机号唯一性):基于手机号查询是否已经存在该手机号,如果存在则返回异常。
    2. 从redis中获取验证码,与前端传入的验证码进行一致性校验,如果不一致则抛出异常
    3. 删除redis中的验证码
    4. 创建用户对象,填入参数并补充其它默认值
    5. 对密码进行加密
    6. 保存用户对象到数据库
  • 编码实现:

    1. controller

    2. 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:
文章来源:https://blog.csdn.net/m0_54187478/article/details/135664937
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。