登录校验
实现登陆后才能访问后端系统页面，不登陆则跳转登陆页面进行登陆。
首先我们在宏观上先有一个认知：
HTTP协议是无状态协议。即每一次请求都是独立的，下一次请求并不会携带上一次请求的数据。
因此当我们通过浏览器访问登录后，接下来我们执行其他业务操作时，服务器无法判断用户是否登录。
那应该怎么来实现登录校验的操作呢？具体的实现思路可以分为两部分：
- 在登录成功后，需要将用户登录成功的信息存起来，记录用户已经登录成功的标记。
- 在浏览器发起请求时，需要在服务端进行统一拦截，拦截后进行登录校验。
如果在每一个功能中都添加判断逻辑就会出现相同代码逻辑，每个功能都需要编写，就会造成代码非常繁琐。
为了简化这块操作，我们可以使用：统一拦截技术。
统一拦截技术：
拦截浏览器发送过来的所有请求，拦截后通过请求来获取之前所存入的登录标记。，以此判断是否放行。
我们要完成以上操作，会涉及到web开发中的两个技术：
- 会话技术
- 统一拦截技术
- Servlet规范中的Filter过滤器
- Spring提供的interceptor拦截器
会话技术
什么是会话？
- 浏览器与服务器之间的一次连接，我们就称为一次会话。
- 用户打开浏览器，访问wb服务器的资源，会话建立，直到有一方断开连接，会话结束。
- 在一次会话中可以包含多次请求和响应。
会话跟踪
会话跟踪：一种维护浏览器状态的方法，服务器需要识别多次请求是否来自于同一浏览器，以便在同一次会话的多次请求间共享数据。
识别多次请求是否来自于同一浏览器的过程，我们就称为会话跟踪。
为什么要共享数据呢？
由于HTTP是无状态协议，在后面请求中怎么拿到前一次请求生成的数据呢？此时就需要在一次会话的多次请求之间进行数据共享
会话跟踪技术有三种：
- Cookie（客户端会话跟踪技术）
- 数据存储在客户端浏览器
- Session（服务端会话跟踪技术）
- 数据存储在服务端
- 令牌技术
会话跟踪方案
方案一：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/响应Cookiereturn 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();}
}
- 访问c1接口，设置Cookie，http://localhost:8080/c1
我们可以看到，设置的cookie，通过响应头Set-Cookie响应给浏览器，并且浏览器会将Cookie，存储在浏览器端。
- 访问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);}
}
- 访问 s1 接口，http://localhost:8080/s1
请求完成之后，在响应头中，就会看到有一个Set-Cookie的响应头，里面响应回来了一个Cookie，就是JSESSIONID，这个就是服务端会话对象 Session 的ID。
- 访问 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？
首先第一点，我们现在所开发的项目，一般都不会只部署在一台服务器上，因为一台服务器会存在一个很大的问题，就是单点故障。所谓单点故障，指的就是一旦这台服务器挂了，整个应用都没法访问了。
