龙岗区住房和建设局官方网站,做网站 卖会员,一个简单网页的代码,wordpress弹出插件一.登录校验的需求
什么是登录校验#xff1f;
所谓登录校验#xff0c;指的是我们在服务器端接收到浏览器发送过来的请求之后#xff0c;首先我们要对请求进行校验。先要校验一下用户登录了没有#xff0c;如果用户已经登录了#xff0c;就直接执行对应的业务操作就可以…一.登录校验的需求
什么是登录校验
所谓登录校验指的是我们在服务器端接收到浏览器发送过来的请求之后首先我们要对请求进行校验。先要校验一下用户登录了没有如果用户已经登录了就直接执行对应的业务操作就可以了如果用户没有登录此时就不允许他执行相关的业务操作直接给前端响应一个错误的结果最终跳转到登录页面要求他登录成功之后再来访问对应的数据。
了解完什么是登录校验之后接下来我们分析一下登录校验大概的实现思路。
首先我们在宏观上先有一个认知
前面在讲解HTTP协议的时候我们提到HTTP协议是无状态协议。什么又是无状态的协议
所谓无状态指的是每一次请求都是独立的下一次请求并不会携带上一次请求的数据。而浏览器与服务器之间进行交互基于HTTP协议也就意味着现在我们通过浏览器来访问了登陆这个接口实现了登陆的操作接下来我们在执行其他业务操作时服务器也并不知道这个员工到底登陆了没有。因为HTTP协议是无状态的两次请求之间是独立的所以是无法判断这个员工到底登陆了没有。
那应该怎么来实现登录校验的操作呢具体的实现思路可以分为两部分
1. 在登录成功后需要将用户登录成功的信息存起来记录用户已经登录成功的标记。 2. 在浏览器发起请求时需要在服务端进行统一拦截拦截后进行登录校验。
我们要完成以上操作会涉及到web开发中的两个技术
1. 会话技术 2. 统一拦截技术过滤器Interceptor与拦截器Filter_前端interceptor拦截器-CSDN博客
二.会话技术
什么是会话 在我们日常生活当中会话指的就是谈话、交谈。在web开发当中会话指的就是浏览器与服务器之间的一次连接我们就称为一次会话。 在用户打开浏览器第一次访问服务器的时候这个会话就建立了直到有任何一方断开连接此时会话就结束了。在一次会话当中是可以包含多次请求和响应的。 比如打开了浏览器来访问web服务器上的资源浏览器不能关闭、服务器不能断开 第1次访问的是登录的接口完成登录操作 第2次访问的是部门管理接口查询所有部门数据 第3次访问的是员工管理接口查询员工数据 只要浏览器和服务器都没有关闭以上3次请求都属于一次会话当中完成的。同一个浏览器在未关闭之前请求了多次服务器这多次请求是属于同一个会话。 知道了会话的概念了接下来我们再来了解下会话跟踪。
会话跟踪一种维护浏览器状态的方法服务器需要识别多次请求是否来自于同一浏览器以便在同一次会话的多次请求间共享数据。 服务器会接收很多的请求但是服务器是需要识别出这些请求是不是同一个浏览器发出来的。比如1和2这两个请求是不是同一个浏览器发出来的3和5这两个请求不是同一个浏览器发出来的。如果是同一个浏览器发出来的就说明是同一个会话。如果是不同的浏览器发出来的就说明是不同的会话。而识别多次请求是否来自于同一浏览器的过程我们就称为会话跟踪。 我们使用会话跟踪技术就是要完成在同一个会话中多个请求之间进行共享数据。 为什么要共享数据呢 由于HTTP是无状态协议在后面请求中怎么拿到前一次请求生成的数据呢此时就需要在一次会话的多次请求之间进行数据共享。 会话跟踪技术有两种
1. Cookie客户端会话跟踪技术 - 数据存储在客户端浏览器当中 2. Session服务端会话跟踪技术 - 数据存储在储在服务端 3. 令牌技术
三.会话跟踪方案
接下来我们就来对比一下这 3 种会话跟踪的技术方案来看一下具体的实现思路以及它们之间的优缺点。
1.方案一--Cookie cookie 是客户端会话跟踪技术它是存储在客户端浏览器的我们使用 cookie 来跟踪会话我们就可以在浏览器第一次发起请求来请求服务器的时候我们在游览器设置一个cookie。
比如第一次请求了登录接口登录接口执行完成之后我们就可以设置一个cookie在 cookie 当中我们就可以来存储用户相关的一些数据信息。比如我可以在 cookie 当中来存储当前登录用户的用户名用户的ID。
服务器端在给客户端在响应数据的时候会自动的将 cookie 响应给浏览器浏览器接收到响应回来的 cookie 之后会自动的将 cookie 的值存储在浏览器本地。接下来在后续的每一次请求当中都会将浏览器本地所存储的 cookie 自动地携带到服务端。
接下来在服务端我们就可以获取到 cookie 的值。我们可以去判断一下这个 cookie 的值是否存在如果不存在这个cookie就说明客户端之前是没有访问登录接口的如果存在 cookie 的值就说明客户端之前已经登录完成了。这样我们就可以基于 cookie 在同一次会话的不同请求之间来共享数据。
我刚才在介绍流程的时候用了 3 个自动
- 服务器会自动的将 cookie 响应给浏览器。
- 浏览器接收到响应回来的数据之后会自动的将 cookie 存储在浏览器本地。
- 在后续的请求当中浏览器会自动的将 cookie 携带到服务器端。 为什么这一切都是自动化进行的 是因为 cookie 它是 HTP 协议当中所支持的技术而各大浏览器厂商都支持了这一标准。在 HTTP 协议官方给我们提供了一个响应头和请求头 - 响应头 Set-Cookie 设置Cookie数据的 - 请求头 Cookie携带Cookie数据的 优缺点 优点HTTP协议中支持的技术像Set-Cookie 响应头的解析以及 Cookie 请求头数据的携带都是浏览器自动进行的是无需我们手动操作的 缺点很多很多 1.移动端APP(Android、IOS)中无法使用Cookie 2.不安全用户可以自己禁用Cookie 3.Cookie不能跨域 这里主要讲一下第三点 什么是跨域呢跨域问题的原理及解决方法-CSDN博客 但是其实我们很多时候后端都会允许跨域所以一般第三个缺点不成问题。 2.方案二 - Session
前面介绍的时候我们提到Session它是服务器端会话跟踪技术所以它是存储在服务器端的。而 Session 的底层其实就是基于我们刚才所介绍的 Cookie 来实现的。 【1】获取Session
如果我们现在要基于 Session 来进行会话跟踪浏览器在第一次请求服务器的时候我们就可以直接在服务器当中来获取到会话对象Session。如果是第一次请求Session 会话对象是不存在的这个时候服务器会自动的创建一个会话对象Session 。而每一个会话对象Session 它都有一个ID示意图中Session后面括号中的1就表示ID我们称之为 Session 的ID。
【2】响应Cookie (JSESSIONID) 【3】查找Session 接下来在后续的每一次请求当中都会将 Cookie 的数据获取出来并且携带到服务端。接下来服务器拿到JSESSIONID这个 Cookie 的值也就是 Session 的ID。拿到 ID 之后就会从众多的 Session 当中来找到当前请求对应的会话对象Session。
这样我们是不是就可以通过 Session 会话对象在同一次会话的多次请求之间来共享数据了好这就是基于 Session 进行会话跟踪的流程。
【4】总结
简单说就是将每个会话的信息存入服务端作为session。然后返回存储携带对应JSESSIONID的cokkie每次请求返回cookie提取JSESSIONID然后服务端就能找到对应的session。
cookie是将信息存放在客户端而session是将信息存放在服务端客户端只存储对应的 session-id。
【5】代码示例与优缺点
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);}
}
优缺点 优点Session是存储在服务端的安全 缺点 因为Session独属于一台服务器服务器集群环境【多台服务器部署应用】下无法直接使用Session需要再不同服务器间进行session拷贝。 移动端APP(Android、IOS)中无法使用Cookie 用户可以自己禁用Cookie Cookie不能跨域 注Session 底层是基于Cookie实现的会话跟踪所以Session继承了Cookie的缺点。 大家会看到上面这两种传统的会话技术在现在的企业开发当中是不是会存在很多的问题。 为了解决这些问题在现在的企业开发当中基本上都会采用第三种方案通过令牌技术来进行会话跟踪。接下来我们就来介绍一下令牌技术来看一下令牌技术又是如何跟踪会话的。
3.方案三-令牌技术
令牌其实它就是一个用户身份的标识看似很高大上很神秘其实本质就是一个字符串。 如果通过令牌技术来跟踪会话我们就可以在浏览器发起请求。在请求登录接口的时候如果登录成功我就可以生成一个令牌令牌就是用户的合法身份凭证。接下来我在响应数据的时候我就可以直接将令牌响应给前端。
接下来我们在前端程序当中接收到令牌之后就需要将这个令牌存储起来。这个存储可以存储在 cookie 当中也可以存储在其他的存储空间(比如localStorage)当中。
接下来在后续的每一次请求当中都需要将令牌携带到服务端。携带到服务端之后接下来我们就需要来校验令牌的有效性。如果令牌是有效的就说明用户已经执行了登录操作如果令牌是无效的就说明用户之前并未执行登录操作。
此时如果是在同一次会话的多次请求之间我们想共享数据我们就可以将共享的数据存储在令牌当中就可以了。
总结其实也和cookie差不多不一样的是因为token可以存储在其他地方所以不止支持网页。另外token经过加密安全型比cookie高(不过cookie也可以加密)。
优缺点
优点 支持PC端、移动端【对比cokkie】 解决集群环境下的认证问题【对比session】 减轻服务器的存储压力【对比session不过也不一定因为有时候我们会存储token来判断用户是否登录登出】 缺点需要自己实现生成传递和校验这些需要消耗一定的服务器资源。
关于JWT的相关知识看下一篇学习笔记
JWT(JSON Web Token)--JSON Web令牌_令牌报文采用json格式-CSDN博客
