【JavaWeb】登录校验-会话技术（一）Cookie与Session

登录校验

实现登陆后才能访问后端系统页面，不登陆则跳转登陆页面进行登陆。

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

HTTP协议是无状态协议。即每一次请求都是独立的，下一次请求并不会携带上一次请求的数据。
因此当我们通过浏览器访问登录后，接下来我们执行其他业务操作时，服务器无法判断用户是否登录。

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

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

如果在每一个功能中都添加判断逻辑就会出现相同代码逻辑，每个功能都需要编写，就会造成代码非常繁琐。
为了简化这块操作，我们可以使用：统一拦截技术。

统一拦截技术：
拦截浏览器发送过来的所有请求，拦截后通过请求来获取之前所存入的登录标记。，以此判断是否放行。

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

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

• Servlet规范中的Filter过滤器
• Spring提供的interceptor拦截器
  

会话技术

什么是会话？

• 浏览器与服务器之间的一次连接，我们就称为一次会话。
• 用户打开浏览器，访问wb服务器的资源，会话建立，直到有一方断开连接，会话结束。
• 在一次会话中可以包含多次请求和响应。

会话跟踪

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

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

会话跟踪技术有三种：

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

会话跟踪方案

方案一：Cookie

cookie 是客户端会话跟踪技术，它是存储在客户端浏览器的，我们使用 cookie 来跟踪会话，就可以在浏览器第一次发起请求来请求服务器的时候，我们在服务器端来设置一个cookie。
在 cookie 当中我们可以来存储用户相关的一些数据信息。比如当前登录用户的用户名，用户的ID。

服务器端在给客户端在响应数据的时候

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

通过获取到的 cookie 值我们就可以判断当前用户是否登录。

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

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

代码演示

@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();
    }
} 

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

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

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

优缺点

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

跨域介绍：

• 现在的项目，大部分都是前后端分离的，前后端最终也会分开部署，前端部署在服务器 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	不跨域

方案二：Session

Session 的底层其实就是基于刚才所介绍的 Cookie 来实现的。

• 获取Session
  

  • 浏览器在第一次请求服务器的时候，我们就可以直接在服务器当中来获取到会话对象Session。
  • 如果是第一次请求Session ，会话对象是不存在的，这个时候服务器会自动的创建一个会话对象Session 。
  • 每一个会话对象Session ，它都有一个ID（示意图中Session后面括号中的1，就表示ID），我们称之为 Session 的ID。

• 响应Cookie (JSESSIONID)
  

  • 服务器端在给浏览器响应数据的时候，它会将 Session 的 ID 通过 Cookie 响应给浏览器。
  • 在响应头当中增加了一个 Set-Cookie 响应头。这个 Set-Cookie 响应头对应的值是cookie，cookie 的名字是固定的 JSESSIONID 代表的服务器端会话对象 Session 的 ID。
  • 浏览器会自动识别这个响应头，然后自动将Cookie存储在浏览器本地。

• 查找Session
  

  • 接下来，在后续的每一次请求当中，都会将 Cookie 的数据获取出来，并且携带到服务端。接下来服务器拿到JSESSIONID这个 Cookie 的值，也就是 Session 的ID。拿到 ID 之后，就会从众多的 Session 当中来找到当前请求对应的会话对象Session。

这样就可以通过 Session 会话对象在同一次会话的多次请求之间来共享数据了，这就是基于 Session 进行会话跟踪的流程。

代码演示

@Slf4j
@RestController
public class SessionController {

    @GetMapping("/s1")
    public Result session1(HttpSession session){
        log.info("HttpSession-s1: {}", session.hashCode());

        session.setAttribute("loginUser", "tom"); //往session中存储数据
        return Result.success();
    }

    @GetMapping("/s2")
    public Result session2(HttpServletRequest request){
        HttpSession session = request.getSession();
        log.info("HttpSession-s2: {}", session.hashCode());

        Object loginUser = session.getAttribute("loginUser"); //从session中获取数据
        log.info("loginUser: {}", loginUser);
        return Result.success(loginUser);
    }
}

1. 访问 s1 接口，http://localhost:8080/s1
   

请求完成之后，在响应头中，就会看到有一个Set-Cookie的响应头，里面响应回来了一个Cookie，就是JSESSIONID，这个就是服务端会话对象 Session 的ID。

2. 访问 s2 接口，http://localhost:8080/s2
   

接下来，在后续的每次请求时，都会将Cookie的值，携带到服务端，服务端接收到Cookie之后，会自动的根据JSESSIONID的值，找到对应的会话对象Session。

那经过这两步测试，大家也会看到，在控制台中输出如下日志：

两次请求，获取到的Session会话对象的hashcode是一样的，就说明是同一个会话对象。而且，第一次请求时，往Session会话对象中存储的值，第二次请求时，也获取到了。 那这样，我们就可以通过Session会话对象，在同一个会话的多次请求之间来进行数据共享了。

优缺点

• 优点：Session是存储在服务端的，安全
• 缺点：
  • 服务器集群环境下无法直接使用Session
  • 移动端APP(Android、IOS)中无法使用Cookie
  • 用户可以自己禁用Cookie
  • Cookie不能跨域

PS：Session 底层是基于Cookie实现的会话跟踪，如果Cookie不可用，则该方案，也就失效了。

服务器集群环境为何无法使用Session？

首先第一点，我们现在所开发的项目，一般都不会只部署在一台服务器上，因为一台服务器会存在一个很大的问题，就是单点故障。所谓单点故障，指的就是一旦这台服务器挂了，整个应用都没法访问了。
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/ffd4ee2143a1477aaf51202a3712d06d.png#pic_center

• 所以在现在的企业项目开发当中，最终部署的时候都是以集群的形式来进行部署，也就是同一个项目它会部署多份。
• 而用户在访问的时候，他会访问一台前置的服务器，我们叫负载均衡服务器，它的作用就是将前端发起的请求均匀的分发给后面的这三台服务器。
  此时假如我们通过 session 来进行会话跟踪，可能就会存在这样一个问题。
• 用户打开浏览器要进行登录操作，此时会发起登录请求。登录请求到达负载均衡服务器，将这个请求转给了第一台 Tomcat 服务器。
• 服务器接收到请求后，获取到会话对象session，然后给浏览器响应数据和携带一个cookie。
• 此时，我们再执行一次操作，这次请求到达负载均衡服务器之后，负载均衡服务器将这次请求转给了第二台 Tomcat 服务器，此时他就要到第二台 Tomcat 服务器当中根据JSESSIONID 也就是对应的 session 的 ID 值，要找对应的 session 会话对象。
• 显然，第二台服务器当中并没有这个ID的会话对象 Session。
  同一个浏览器发起了 2 次请求，结果获取到的不是同一个会话对象，这就是Session这种会话跟踪方案它的缺点，在服务器集群环境下无法直接使用Session。