实现的效果就是用户必须登录之后,才可以访问后台系统中的功能。
1、登录需求
1.1需求
在这个页面用户可以输入用户名及密码,然后点击“登录"按钮就要请求服务器,服务端判断用户输入的用户名或者密码是否正确,则返回成功结果,前端跳转只系统首页。
1.2思路
登录服务端的核心逻辑就是:接受前端请求传递的用户名和密码,然后在根据用户名和密码查询用户信息,如果用户信息存在则说明用户输入的用户名密码是正确的,如果查询的用户不存在,则用户输入的密码是错误的。
1.3实现
1)LoginController
2). EmpService / EmpServiceImpl
3). EmpMapper
1.4测试
功能开发完毕后,就可以启动服务,打开postman进行测试了。 发起POST请求,访问:http://localhost:8080/login
1.5问题
没有输入账户密码也是可以登录网页的,要想解决这个问题,更重要的是登录后的校验操作。
2、登录校验
2.1
- 在员工登录成功后,需要将用户登录成功的信息,存起来,记录用户已经登录成功的标记。
- 在浏览器发起请求时,需要在服务端进行统一拦截,然后读取登录标记中的信息,如果有登录成功的信息,就说明用户登录成功,放行请求,如果发现登录标记中没有登录成功的标记,则给前端返回错误信息,跳转至登录页面。
- 统一拦截:可以使用两种技术实现,Filter过滤器以及interceptor拦截器
- 登录标记:就是需要用户登录成功之后,每一次请求中都可以获取到该标记。
此标记需要在用户登录成功之后,每一个请求资源中,都可以获取到也就是说可以在多次请求间共享。但是我们之前介绍过,HTTP是无状态的,不能在多次请求间共享数据,所以,此处需要使用会话跟踪技术来解决。
Filter、Interceptor。
2.2会话技术
那么该如何实现会话技术?具体的方式有:
1)客户端会话跟踪技术:Cookie
2)服务端会话跟踪技术:Session
这样前端浏览器访问该登录方法之后,与该方法就建立起了一个会话,那么此时服务器会给浏览器响应数据的同时,返回一个响应头 set-cookie,值呢就是服务器会话session的ID
2.23问题分析
在现今前后端分离开发的模式下,Cookie,session这种会话技术已经很少用了,而且在服务器环境下以及客户端多样化的情况下,传统的Cookie,Session的会话方案已经力不存心了,其主要体现在两个方面:
- 服务端集群环境下Session的共享问题。
- 移动App端无法使用Cookie
2.3 JWT令牌
- Json Wed Token(JWT)是一个开放的行业标准(RFC7519),它定义一种简洁的,自包含的协议格式,用于在通信双方传递json对象,传递的信息经过数字签名可以被验证和信任。
- 官网: JSON Web Tokens - jwt.io
- 标准: RFC 7519 - JSON Web Token (JWT)
- 优点:
-
- 使用 json 作为数据传输,有广泛的通用型,并且体积小,便于传输;
- 不需要在服务器端保存相关信息;
- jwt 载荷部分可以存储业务相关的信息(非敏感的),例如用户信息、角色等;
2.32组成
JWT令牌由Header、Payload、Signature三部分组成,每部分中间使用点(.)分隔,比如:xxxxx.yyyyy.zzzzz
-
第一部分:Header(头),作用:记录令牌类型、签名算法等。 比如
- 将上边的内容使用Base64编码,得到一个字符串就是JWT令牌的第一部分。
-
将上边的内容使用Base64编码,得到一个字符串就是JWT令牌的第一部分。
最后将第二部分负载使用Base64编码,得到一个字符串就是JWT令牌的第二部分。
最后将第二部分负载使用Base64编码,得到一个字符串就是JWT令牌的第二部分。
base64UrlEncode(header):jwt令牌的第一部分。
base64UrlEncode(payload):jwt令牌的第二部分。
secret:签名所使用的密钥
2.3.3 生成
1). pom.xml 引入jwt的依赖
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
<version>0.9.1</version>
</dependency>