SpringBootWeb登录认证

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

1. 登录功能

1、需求

在登录界面中，我们可以输入用户的用户名以及密码，然后点击 “登录” 按钮就要请求服务器，服务端判断用户输入的用户名或者密码是否正确。如果正确，则返回成功结果，前端跳转至系统首页面。
2、接口文档
我们参照接口文档来开发登录功能

• 基本信息
  :::info
  请求路径：/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"
}

3、思路分析

登录服务端的核心逻辑就是：接收前端请求传递的用户名和密码 ，然后再根据用户名和密码查询用户信息，如果用户信息存在，则说明用户输入的用户名和密码正确。如果查询到的用户不存在，则说明用户输入的用户名和密码错误。
**4、功能开发7 **
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);
    
    //省略其他代码...
}

5、测试
功能开发完毕后，我们就可以启动服务，打开postman进行测试了。
发起POST请求，访问：http://localhost:8080/login

postman测试通过了，那接下来，我们就可以结合着前端工程进行联调测试。
先退出系统，进入到登录页面：

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

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

2. 登录校验

2.1 问题分析

我们已经完成了基础登录功能的开发与测试，在我们登录成功后就可以进入到后台管理系统中进行数据的操作。
但是当我们在浏览器中新的页面上输入地址：http://localhost:9528/#/system/dept，发现没有登录仍然可以进入到后端管理系统页面。

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

什么是登录校验？

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

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

首先我们在宏观上先有一个认知：前面在讲解HTTP协议的时候，我们提到HTTP协议是无状态协议。什么又是无状态的协议？所谓无状态，指的是每一次请求都是独立的，下一次请求并不会携带上一次请求的数据。而浏览器与服务器之间进行交互，基于HTTP协议也就意味着现在我们通过浏览器来访问了登陆这个接口，实现了登陆的操作，接下来我们在执行其他业务操作时，服务器也并不知道这个员工到底登陆了没有。因为HTTP协议是无状态的，两次请求之间是独立的，所以是无法判断这个员工到底登陆了没有。
那应该怎么来实现登录校验的操作呢？具体的实现思路可以分为两部分：

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

想要判断员工是否已经登录，我们需要在员工登录成功之后，存储一个登录成功的标记，接下来在每一个接口方法执行之前，先做一个条件判断，判断一下这个员工到底登录了没有。如果是登录了，就可以执行正常的业务操作，如果没有登录，会直接给前端返回一个错误的信息，前端拿到这个错误信息之后会自动的跳转到登录页面。
我们程序中所开发的查询功能、删除功能、添加功能、修改功能，都需要使用以上套路进行登录校验。此时就会出现：相同代码逻辑，每个功能都需要编写，就会造成代码非常繁琐。
为了简化这块操作，我们可以使用一种技术：统一拦截技术。
通过统一拦截的技术，我们可以来拦截浏览器发送过来的所有的请求，拦截到这个请求之后，就可以通过请求来获取之前所存入的登录标记，在获取到登录标记且标记为登录成功，就说明员工已经登录了。如果已经登录，我们就直接放行(意思就是可以访问正常的业务接口了)。
我们要完成以上操作，会涉及到web开发中的两个技术：

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

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

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

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

2.2 会话技术

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

2.2.1 会话技术介绍

什么是会话？

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

需要注意的是：会话是和浏览器关联的，当有三个浏览器客户端和服务器建立了连接时，就会有三个会话。同一个浏览器在未关闭之前请求了多次服务器，这多次请求是属于同一个会话。比如：1、2、3这三个请求都是属于同一个会话。当我们关闭浏览器之后，这次会话就结束了。而如果我们是直接把web服务器关了，那么所有的会话就都结束了。
知道了会话的概念了，接下来我们再来了解下会话跟踪。
会话跟踪：一种维护浏览器状态的方法，服务器需要识别多次请求是否来自于同一浏览器，以便在同一次会话的多次请求间共享数据。
服务器会接收很多的请求，但是服务器是需要识别出这些请求是不是同一个浏览器发出来的。比如：1和2这两个请求是不是同一个浏览器发出来的，3和5这两个请求是不是同一个浏览器发出来的。如果是同一个浏览器发出来的，就说明是同一个会话。如果是不同的浏览器发出来的，就说明是不同的会话。而识别多次请求是否来自于同一浏览器的过程，我们就称为会话跟踪。
我们使用会话跟踪技术就是要完成在同一个会话中，多个请求之间进行共享数据。
为什么要共享数据呢？
由于HTTP是无状态协议，在后面请求中怎么拿到前一次请求生成的数据呢？此时就需要在一次会话的多次请求之间进行数据共享
会话跟踪技术有两种：

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

我们今天解决的登录校验就需要使用到服务端会话跟踪技术Session。当用户登录成功之后，就可以将登录标记存储到Session会话对象当中。接下来我们在统一拦截的时候，我们只需要从Session会话对象当中来拿到登录标记。如果拿到了登录标记，就说明用户已经登录了，直接放行执行对应的接口方法。如果没有拿到登录标记，就说明用户没有登录，直接响应错误的信息，前端跳转到登录页面就可以了。
我们要使用的会话对象Session，它有一个标准的接口： HttpSession。而获取Session对象方式：

1. 将HttpSession会话对象作为controller方法参数传入
2. 通过HttpServletRequest对象获取，调用getSession()方法

下面我们就来演示下HttpSession会话对象。我们来看一下通过session会话对象能不能在同一次会话的多次请求之间来共享数据。

import com.itheima.pojo.Result;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

/**
 * HttpSession演示
 */
@Slf4j
@RestController
public class SessionController {
   

    //将HttpSession会话对象作为controller方法参数传入
    @GetMapping("/s1")
    public Result session1(HttpSession session){
   
        log.info("HttpSession-s1: {}", session.hashCode());

        //向会话对象中存储一个数据（问题：当前会话中多次请求响应时可否使用存储在会话中的数据）
        session.setAttribute("loginUser", "tom"); //登录标记（存储在Session会话中）

        return Result.success();
    }

    //通过HttpServletRequest对象调用getSession()方法获取
    @GetMapping("/s2")
    public Result session2(HttpServletRequest request){
   
        //根据请求获取一个Session对象
        HttpSession session = request.getSession();

        log.info("HttpSession-s2: {}", session.hashCode());

        //从会话对象中获取一个数据
        Object loginUser = session.getAttribute("loginUser"); //从session中获取数据

        log.info("loginUser: {}", loginUser);
        
        return Result.success(loginUser);
    }
}

我们打开谷歌浏览器直接输入：http://localhost:8080/s1 ，可以看到控制台输出：

接着我们使用谷歌浏览器再来访问：http://localhost:8080/s2 ，可以看到控制台输出：

通过以上案例我们验证了在一个会话的多次请求之间可以进行数据共享。我们只需要把共享的数据存储到session对象中。（在同一个会话的多次请求之间，我们拿到的会话对象是同一个）
接下来我们再来做一个测试：
更换另一个浏览器软件(如：Firefox火狐浏览器)，在地址栏中输入：http://localhost:8080/s1 ，查看控制台输出，看看当前Session会话对象的哈希code还和之前使用谷歌浏览器访问时的一样吗？
通过以上测试我们应该可以看到两个不同会话对象的哈希code值，一个是谷歌浏览器建立的会话，另一个是火狐浏览器建立的会话。
服务端Session对象的基本操作：

• 存储：void setAttribute(String name, Object value);
• 获取：Object getAttribute(String name);
• 删除：void removeAttribute(String name);
• 销毁：void invalidate(); //服务器端直接将session对象销毁
  

2.2.2 会话技术原理

简单介绍了服务器端会话对象session之后，接下来我们再来分析一下它的原理。看看为什么我们在同一个会话的不同请求之间，获取到的是同一个会话对象session。而要想说明这个原理，我们就不得不提到另外一个会话对象：Cookie(客户端会话对象)，因为session就是基于cookie来实现的。

当我们打开浏览器，第一次在请求服务器的时候，这个会话就建立了。在服务器端，我们要获取会话对象，服务器端会自动判断是否存在当前这个Session会话对象，如果存在就直接使用，如果不存在，则会创建一个新的Session会话对象，并且还会为每一个会话对象都分配一个唯一标识ID。当session会话对象创建好了之后，服务器端在给浏览器响应数据的时候，服务器端会把cookie一起响应给浏览器，而cookie对应的值就是 session的ID，它的名字就叫：JSESSIONID

Cookie是客户端会话对象，它是保存在浏览器端的，所以此时浏览器接收到cookie后，会自动的将Cookie中的数据保存到本地浏览器。

当浏览器再向服务端发起请求时，每一次的请求都会将存储在浏览器本地的Cookie值携带到服务端，而Cookie的值就是Session的ID，此时服务端就会拿到Session的ID值，然后根据Session的ID自动找到对应的Session对象，这样就能够保证我们在同一次会话的多次请求之间获取到的是同一个Session会话对象，这样就保证了可以通过会话对象Session在多次请求之间来共享数据，这就是Session的实现原理。
这种基于Cookie实现Session的会话跟踪技术，是会话跟踪的传统解决方案。这种传统的解决方案在web开发的早期使用的是非常普遍的，但是在PC互联网以及移动互联网高速发展的今天来说，已经不再适用了，因为会存在很多的问题。接下来我们就来分析一下到底存在什么样的问题，以及新的解决方案是什么样子的。
传统Session会话跟踪技术存在的问题：

1. 服务端集群环境下Session同步问题
2. 移动端APP无法使用Cookie

现在我们所开发的项目一般都不会只部署在一台服务器上，因为单台服务器它的承载能力是有限的。如果只部署在一台Tomcat服务器上，当这个单台服务器断电了、断网了、或服务器硬件坏了，就会造成整个服务都没法访问了，此时所有的用户也都不能访问到所部署的项目了。所以在当下的项目开发中，基本上都会以集群的方式来进行部署。所谓集群的方式来部署，指的就是同一个项目，会部署在不同的服务器上，部署多份，即使其中一台服务器 down掉了，还有其他服务器可以正常使用。
此时也出现了另一个问题：项目部署在了3台服务器上，用户在访问的时候到底访问哪一台服务器？
答案：此时用户在访问的时候，会先访问前置服务器（负载均衡服务器）。
我们在后面项目课程中会讲到负载均衡服务器，目前大家先有一个印象：请求到达负载均衡服务器之后，负载均衡服务器会将这个请求转给后端的Tomcat服务器，请求只会转给其中的一台Tomcat服务器。此时所有的请求压力是由这3台Tomcat服务器来平均分配。
服务端集群环境下Session同步存在问题：

• 在浏览器发起登录请求时，请求到达负载均衡服务器，并将请求转给了第一台Tomcat服务器。而第一台Tom cat服务器执行过登录操作后，会在当前服务器上存储一个登录成功的标记，而登录成功的标记我们要存储在 session 会话对象当中，此时在第一台服务器当中就会生成这么一个 session 会话对象。接下来在给浏览器响应数据的时候，会再给浏览器响应一个cookie， cookie当中存储的JSESSIONID=1，浏览器接收到cookie之后会将cookie存储在浏览器本地。下一次浏览器再发起请求的时候，就会将cookie携带到服务端。假如浏览器又发起了查询部门数据的请求，请求到达负载均衡服务器后，将这个请求转给了第二台Tomcat服务器，此时第二台Tomcat服务器就会接收到传递过来的cookie值JSESSION=1，而第二台Tomcat服务器上是没有sessionID为1的Session会话对象的。

移动端APP无法使用Cookie：

• 我们现在所使用的客户端，不仅仅有PC端的浏览器，还有像移动端的APP，还有移动端的小程序。而对于 APP来说，它是不支持cookie的。如果不支持cookie，整个session会话跟踪技术也就不能使用了。

基于我们前面的分析，可以得出一个结论：Session和Cookie已不适应现在的互联网技术开发了。那么在现在的项目开发当中又是如何来跟踪会话的呢？

在现在的项目当中，其实最为常见、最为流行的就是令牌技术。这里我们先简单介绍一下令牌技术大概的实现思路，稍后我们再来详细讲解令牌技术。
令牌技术的大概实现思路是：在浏览器发起请求来执行登录操作，登录成功之后生成一个令牌(就是一个特殊的字符串)，这个令牌就是用户身份的合法凭证。请求完成之后，会将令牌发送给客户端浏览器或者是APP，客户端接收到令牌之后，就将这个令牌存储起来，这个令牌就是他身份的合法凭证。接下来，在以后的请求当中，都会将令牌携带到服务端。在服务端，首先我们先要进行统一拦截，拦截到令牌之后，先判断下这次请求有没有带令牌。如果没有携带令牌，那就说明没有登录，直接响应错误信息，然后跳转到登录页面。如果携带了令牌，还需要校验一下这