526互联

SpringBootWeb登录认证 上

发布时间 2023-10-11 10:32:13作者: 伊吹萃香

案例-登录认证

在前面的课程中，我们已经实现了部门管理、员工管理的基本功能，但是大家会发现，我们并没有登录，就直接访问到了Tlias智能学习辅助系统的后台。 这是不安全的，所以我们今天的主题就是登录认证。 最终我们要实现的效果就是用户必须登录之后，才可以访问后台系统中的功能。

fig:

1. 登录功能

1.1 需求

fig:

在登录界面中，我们可以输入用户的用户名以及密码，然后点击 "登录" 按钮就要请求服务器，服务端判断用户输入的用户名或者密码是否正确。如果正确，则返回成功结果，前端跳转至系统首页面。

1.2 接口文档

我们参照接口文档来开发登录功能

  • 基本信息
  • 请求路径：/login

    请求方式：POST

    接口描述：该接口用于员工登录Tlias智能学习辅助系统，登录完毕后，系统下发JWT令牌。
  • 请求参数
  • 参数格式：application/json
  • 参数说明：

名称

类型

是否必须

备注

username

string

必须

用户名

password

string

必须

密码

  • 请求数据样例：
  • {
    "username": "jinyong",
    "password": "123456"
    }
  • 响应数据
  • 参数格式：application/json
  • 参数说明：

名称

类型

是否必须

默认值

备注

其他信息

code

number

必须

响应码, 1 成功 ; 0 失败

msg

string

非必须

提示信息

data

string

必须

返回的数据 , jwt令牌

  • 响应数据样例：
  • {
    "code": 1,
    "msg": "success",
    "data": "eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoi6YeR5bq4IiwiaWQiOjEsInVzZXJuYW1lIjoiamlueW9uZyIsImV4cCI6MTY2MjIwNzA0OH0.KkUc_CXJZJ8Dd063eImx4H9Ojfrr6XMJ-yVzaWCVZCo"
    }

1.3 思路分析

fig:

登录服务端的核心逻辑就是：接收前端请求传递的用户名和密码 ，然后再根据用户名和密码查询用户信息，如果用户信息存在，则说明用户输入的用户名和密码正确。如果查询到的用户不存在，则说明用户输入的用户名和密码错误。

1.4 功能开发

LoginController

@RestController
public class LoginController {

@Autowired
private EmpService empService;

@PostMapping("/login")
public Result login(@RequestBody Emp emp){
Emp e = empService.login(emp);
return e != null ? Result.success():Result.error("用户名或密码错误");
}
}

EmpService

public interface EmpService {

/**
* 用户登录
* @param emp
* @return
*/
public Emp login(Emp emp);

//省略其他代码...
}

EmpServiceImpl

@Slf4j
@Service
public class EmpServiceImpl implements EmpService {
@Autowired
private EmpMapper empMapper;

@Override
public Emp login(Emp emp) {
//调用dao层功能：登录
Emp loginEmp = empMapper.getByUsernameAndPassword(emp);

//返回查询结果给Controller
return loginEmp;
}

//省略其他代码...
}

EmpMapper

@Mapper
public interface EmpMapper {

@Select("select id, username, password, name, gender, image, job, entrydate, dept_id, create_time, update_time " +
"from emp " +
"where username=#{username} and password =#{password}")
public Emp getByUsernameAndPassword(Emp emp);

//省略其他代码...
}

1.5 测试

功能开发完毕后，我们就可以启动服务，打开postman进行测试了。

发起POST请求，访问：http://localhost:8080/login

fig:

postman测试通过了，那接下来，我们就可以结合着前端工程进行联调测试。

先退出系统，进入到登录页面：

fig:

在登录页面输入账户密码：

fig:

登录成功之后进入到后台管理系统页面：

fig:

2. 登录校验

2.1 问题分析

我们已经完成了基础登录功能的开发与测试，在我们登录成功后就可以进入到后台管理系统中进行数据的操作。

但是当我们在浏览器中新的页面上输入地址：http://localhost:9528/#/system/dept，发现没有登录仍然可以进入到后端管理系统页面。

fig:

而真正的登录功能应该是：登陆后才能访问后端系统页面，不登陆则跳转登陆页面进行登陆。

为什么会出现这个问题？其实原因很简单，就是因为针对于我们当前所开发的部门管理、员工管理以及文件上传等相关接口来说，我们在服务器端并没有做任何的判断，没有去判断用户是否登录了。所以无论用户是否登录，都可以访问部门管理以及员工管理的相关数据。所以我们目前所开发的登录功能，它只是徒有其表。而我们要想解决这个问题，我们就需要完成一步非常重要的操作：登录校验。

fig:

什么是登录校验？

  • 所谓登录校验，指的是我们在服务器端接收到浏览器发送过来的请求之后，首先我们要对请求进行校验。先要校验一下用户登录了没有，如果用户已经登录了，就直接执行对应的业务操作就可以了；如果用户没有登录，此时就不允许他执行相关的业务操作，直接给前端响应一个错误的结果，最终跳转到登录页面，要求他登录成功之后，再来访问对应的数据。

了解完什么是登录校验之后，接下来我们分析一下登录校验大概的实现思路。

首先我们在宏观上先有一个认知：

前面在讲解HTTP协议的时候，我们提到HTTP协议是无状态协议。什么又是无状态的协议？

所谓无状态，指的是每一次请求都是独立的，下一次请求并不会携带上一次请求的数据。而浏览器与服务器之间进行交互，基于HTTP协议也就意味着现在我们通过浏览器来访问了登陆这个接口，实现了登陆的操作，接下来我们在执行其他业务操作时，服务器也并不知道这个员工到底登陆了没有。因为HTTP协议是无状态的，两次请求之间是独立的，所以是无法判断这个员工到底登陆了没有。

fig:

那应该怎么来实现登录校验的操作呢？具体的实现思路可以分为两部分：

  1. 在员工登录成功后，需要将用户登录成功的信息存起来，记录用户已经登录成功的标记。
  2. 在浏览器发起请求时，需要在服务端进行统一拦截，拦截后进行登录校验。

想要判断员工是否已经登录，我们需要在员工登录成功之后，存储一个登录成功的标记，接下来在每一个接口方法执行之前，先做一个条件判断，判断一下这个员工到底登录了没有。如果是登录了，就可以执行正常的业务操作，如果没有登录，会直接给前端返回一个错误的信息，前端拿到这个错误信息之后会自动的跳转到登录页面。

我们程序中所开发的查询功能、删除功能、添加功能、修改功能，都需要使用以上套路进行登录校验。此时就会出现：相同代码逻辑，每个功能都需要编写，就会造成代码非常繁琐。

为了简化这块操作，我们可以使用一种技术：统一拦截技术。

通过统一拦截的技术，我们可以来拦截浏览器发送过来的所有的请求，拦截到这个请求之后，就可以通过请求来获取之前所存入的登录标记，在获取到登录标记且标记为登录成功，就说明员工已经登录了。如果已经登录，我们就直接放行(意思就是可以访问正常的业务接口了)。

我们要完成以上操作，会涉及到web开发中的两个技术：

  1. 会话技术
  2. 统一拦截技术

而统一拦截技术现实方案也有两种：

  1. Servlet规范中的Filter过滤器
  2. Spring提供的interceptor拦截器

下面我们先学习会话技术，然后再学习统一拦截技术。

2.2 会话技术

介绍了登录校验的大概思路之后，我们先来学习下会话技术。

2.2.1 会话技术介绍

什么是会话？

  • 在我们日常生活当中，会话指的就是谈话、交谈。
  • 在web开发当中，会话指的就是浏览器与服务器之间的一次连接，我们就称为一次会话。
  • 在用户打开浏览器第一次访问服务器的时候，这个会话就建立了，直到有任何一方断开连接，此时会话就结束了。在一次会话当中，是可以包含多次请求和响应的。
  • 比如：打开了浏览器来访问web服务器上的资源（浏览器不能关闭、服务器不能断开）
    • 第1次：访问的是登录的接口，完成登录操作
    • 第2次：访问的是部门管理接口，查询所有部门数据
    • 第3次：访问的是员工管理接口，查询员工数据
  • 只要浏览器和服务器都没有关闭，以上3次请求都属于一次会话当中完成的。

fig:

需要注意的是：会话是和浏览器关联的，当有三个浏览器客户端和服务器建立了连接时，就会有三个会话。同一个浏览器在未关闭之前请求了多次服务器，这多次请求是属于同一个会话。比如：1、2、3这三个请求都是属于同一个会话。当我们关闭浏览器之后，这次会话就结束了。而如果我们是直接把web服务器关了，那么所有的会话就都结束了。

知道了会话的概念了，接下来我们再来了解下会话跟踪。

会话跟踪：一种维护浏览器状态的方法，服务器需要识别多次请求是否来自于同一浏览器，以便在同一次会话的多次请求间共享数据。

服务器会接收很多的请求，但是服务器是需要识别出这些请求是不是同一个浏览器发出来的。比如：1和2这两个请求是不是同一个浏览器发出来的，3和5这两个请求不是同一个浏览器发出来的。如果是同一个浏览器发出来的，就说明是同一个会话。如果是不同的浏览器发出来的，就说明是不同的会话。而识别多次请求是否来自于同一浏览器的过程，我们就称为会话跟踪。

我们使用会话跟踪技术就是要完成在同一个会话中，多个请求之间进行共享数据。

为什么要共享数据呢？

由于HTTP是无状态协议，在后面请求中怎么拿到前一次请求生成的数据呢？此时就需要在一次会话的多次请求之间进行数据共享

会话跟踪技术有两种：

  1. Cookie（客户端会话跟踪技术）
    • 数据存储在客户端浏览器当中
  2. Session（服务端会话跟踪技术）
    • 数据存储在储在服务端
  3. 令牌技术

2.2.2 会话跟踪方案

上面我们介绍了什么是会话，什么是会话跟踪，并且也提到了会话跟踪 3 种常见的技术方案。接下来，我们就来对比一下这 3 种会话跟踪的技术方案，来看一下具体的实现思路，以及它们之间的优缺点。

2.2.2.1 方案一 - Cookie

cookie 是客户端会话跟踪技术，它是存储在客户端浏览器的，我们使用 cookie 来跟踪会话，我们就可以在浏览器第一次发起请求来请求服务器的时候，我们在服务器端来设置一个cookie。

比如第一次请求了登录接口，登录接口执行完成之后，我们就可以设置一个cookie，在 cookie 当中我们就可以来存储用户相关的一些数据信息。比如我可以在 cookie 当中来存储当前登录用户的用户名，用户的ID。

服务器端在给客户端在响应数据的时候，会自动的将 cookie 响应给浏览器，浏览器接收到响应回来的 cookie 之后，会自动的将 cookie 的值存储在浏览器本地。接下来在后续的每一次请求当中，都会将浏览器本地所存储的 cookie 自动地携带到服务端。

fig:

接下来在服务端我们就可以获取到 cookie 的值。我们可以去判断一下这个 cookie 的值是否存在，如果不存在这个cookie，就说明客户端之前是没有访问登录接口的；如果存在 cookie 的值，就说明客户端之前已经登录完成了。这样我们就可以基于 cookie 在同一次会话的不同请求之间来共享数据。

我刚才在介绍流程的时候，用了 3 个自动：

  • 服务器会 自动 的将 cookie 响应给浏览器。
  • 浏览器接收到响应回来的数据之后，会 自动 的将 cookie 存储在浏览器本地。
  • 在后续的请求当中，浏览器会 自动 的将 cookie 携带到服务器端。

为什么这一切都是自动化进行的？

是因为 cookie 它是 HTP 协议当中所支持的技术，而各大浏览器厂商都支持了这一标准。在 HTTP 协议官方给我们提供了一个响应头和请求头：

  • 响应头 Set-Cookie ：设置Cookie数据的
  • 请求头 Cookie：携带Cookie数据的

fig:

代码测试

@Slf4j
@RestController
public class SessionController {

//设置Cookie
@GetMapping("/c1")
public Result cookie1(HttpServletResponse response){
response.addCookie(new Cookie("login_username","itheima")); //设置Cookie/响应Cookie
return Result.success();
}

//获取Cookie
@GetMapping("/c2")
public Result cookie2(HttpServletRequest request){
Cookie[] cookies = request.getCookies();
for (Cookie cookie : cookies) {
if(cookie.getName().equals("login_username")){
System.out.println("login_username: "+cookie.getValue()); //输出name为login_username的cookie
}
}
return Result.success();
}
}

A. 访问c1接口，设置Cookie，http://localhost:8080/c1

fig:

我们可以看到，设置的cookie，通过响应头Set-Cookie响应给浏览器，并且浏览器会将Cookie，存储在浏览器端。

fig:

B. 访问c2接口 http://localhost:8080/c2，此时浏览器会自动的将Cookie携带到服务端，是通过请求头Cookie，携带的。

fig:

优缺点

  • 优点：HTTP协议中支持的技术（像Set-Cookie 响应头的解析以及 Cookie 请求头数据的携带，都是浏览器自动进行的，是无需我们手动操作的）
  • 缺点：
    • 移动端APP(Android、IOS)中无法使用Cookie
    • 不安全，用户可以自己禁用Cookie
    • Cookie不能跨域

跨域介绍：

image-20230112103840467

  • 现在的项目，大部分都是前后端分离的，前后端最终也会分开部署，前端部署在服务器 192.168.150.200 上，端口 80，后端部署在 192.168.150.100上，端口 8080
  • 我们打开浏览器直接访问前端工程，访问url：http://192.168.150.200/login.html
  • 然后在该页面发起请求到服务端，而服务端所在地址不再是localhost，而是服务器的IP地址192.168.150.100，假设访问接口地址为：http://192.168.150.100:8080/login
  • 那此时就存在跨域操作了，因为我们是在 http://192.168.150.200/login.html 这个页面上访问了http://192.168.150.100:8080/login 接口
  • 此时如果服务器设置了一个Cookie，这个Cookie是不能使用的，因为Cookie无法跨域

区分跨域的维度：

  • 协议
  • IP/协议
  • 端口

只要上述的三个维度有任何一个维度不同，那就是跨域操作

举例：

http://192.168.150.200/login.html ----------> https://192.168.150.200/login [协议不同，跨域]

http://192.168.150.200/login.html ----------> http://192.168.150.100/login [IP不同，跨域]

http://192.168.150.200/login.html ----------> http://192.168.150.200:8080/login [端口不同，跨域]

http://192.168.150.200/login.html ----------> http://192.168.150.200/login [不跨域]