当前位置:首页 > 建站必备 > 正文

本站3天更换一次域名yw

这位作家的写作技巧还很浅薄。如有不妥之处,请大方指出,不胜感激。

饼干

洛:大爷,楼上322住的是马冬梅家吧?大爷:马都什么?夏洛:马冬梅。大爷:什么都没啊?夏洛:马冬梅啊。大爷:马什么没?夏洛:行,大爷你先凉快着吧。

在理解这三个概念之前,我们首先要明白HTTP是一个无状态的Web服务器,什么是无状态?就像上面《再见失败者先生》中的经典对话,一个对话讲完,下一个对话已经不知道上一个发生了什么。如果只是用来管理Web服务器中的静态文件,很容易说对方是谁不重要。只需从磁盘中读取文件并将其发送出去。但随着网络的不断发展,比如电子商务中的购物车,只有记住了用户的身份,才能执行接下来的一系列动作。因此,在这一点上,我们需要我们的无状态服务器记住一些东西。

那么Web服务器是如何记住一些东西的呢?既然Web服务器记不住东西,我们就会尝试在外部记忆,相当于服务器给每个客户端贴一张小纸条。它记录了服务器返回给我们的一些信息。然后服务器看到这个小纸条就知道我们是谁了。那么谁生产饼干呢?Cookies是由服务器生成的。接下来,我们来描述一下Cookie生成的过程。当浏览器第一次访问服务器时,服务器此时当然不知道他的身份,所以它以key=value的格式创建一个唯一的标识数据,放入Set-Cookie字段,和响应消息一起发送给浏览器。

浏览器看到有Set-Cookie字段以后就知道这是服务器给的身份标识,于是就保存起来,下次请求时会自动将此key=value值放入到Cookie字段中发给服务端。服务端收到请求报文后,发现Cookie字段中有值,就能根据此值识别用户的身份然后提供个性化的服务。

接下来,让我们演示如何用代码生成服务器。我们自己搭建后台服务器。在这里,我用SpringBoot来搭建,写入SpringMVC的代码如下。

项目启动后,我们输入路径http://localhost:8005/test cookies,然后检查发送的请求。在下图中可以看到我们第一次访问服务器时发送的请求,并且可以看到服务器返回的响应有一个Set-Cookie字段。而里面的key=value value正是我们服务器里设置的值。

接下来,当我们再次刷新这个页面时,我们可以看到请求体中已经设置了Cookie字段,并且我们的值已经被接管。以便服务器可以根据Cookie中的值记住我们的信息。

另一个要求呢?饼干会和他们一起带来吗?接下来我们输入路径http://localhost:8005 request。我们可以看到Cookie字段仍然被接管。

那么浏览器Cookie存储在哪里呢?如果你使用的是Chrome浏览器,可以按照以下步骤操作。

本站3天更换一次域名yw  第1张

在计算机打开Chrome在右上角,一次点击更多图标->设置在底部,点击高级在隐私设置和安全性下方,点击网站设置依次点击Cookie->查看所有Cookie和网站数据

然后就可以根据域名搜索托管的Cookie数据了。所以是浏览器替你管理cookies的数据。如果此时换成Firefox等其他浏览器,由于刚才Chrome中存储了cookies,服务器又蒙上了。如果你不知道你是谁,你会再给火狐发一个小纸条。

Cookie中的参数设置

说了这么多,要知道Cookie是服务器委托浏览器存储在客户端的一些数据,这些数据通常记录了用户的关键身份信息。因此,cookies需要通过一些其他方式来保护,以防止泄漏或被盗。这些手段就是cookies的属性。

我简单演示一下这些参数的用法和现象。

小路

设置cookie . set path(& # 34;/test cookie & # 34;),然后我们访问http://localhost:8005/test cookies。我们可以看到左边的路径与我们指定的路径相同,所以Cookie出现在请求头中。接下来,我们访问http://localhost: 8005,我们发现没有cookie字段。这是由path控制的路径。

领域

设置cookie . setdomain(& # 34;本地主机& # 34;),然后我们访问http://localhost:8005/test cookies。我们发现下图左侧字段有cookies,但是我们访问http://172 . 16 . 42 . 81:8005/test cookies。如果你看下图的右边,你可以看到没有cookies的字段。这是由发送Cookie的域控制的域名。

下面几个参数就不一一演示了。我相信你应该知道一些关于饼干的事情。

会议

& gtCookie存储在客户端,Session存储在服务器端,客户端只存储SessionId。

在上面,我们知道什么是饼干。既然浏览器已经通过cookies实现了有状态的要求,为什么还会有另一个会话?我们在这里设想一下,如果账户的一些信息存储在Cookie中,一旦信息被拦截,我们的账户信息将全部丢失。所以出现了Session,其中重要信息保存在一个会话中,浏览器只记录SessionId,一个SessionId对应一个会话请求。

这里,我们编写一个新方法来测试会话是如何生成的。我们在请求参数中添加HTTP SESSION,然后在浏览器中输入HTTP://localhost:8005/test SESSION进行访问。我们可以看到,在服务器返回头的Cookie中生成了一个SessionId。然后浏览器记住这个SessionId可以在下次访问的时候带着,然后就可以根据这个Id找到存储在服务器上的信息。

这时我们访问路径http://localhost:8005/test getSession,发现我们得到的是上面session中存储的信息。那么会话什么时候到期?

客户端:和Cookie过期一致,如果没设置,默认是关了浏览器就没了,即再打开浏览器的时候初次请求头中是没有SessionId了。服务端:服务端的过期是真的过期,即服务器端的Session存储的数据结构多久不可用了,默认是30分钟。

现在我们知道会话是在服务器端管理的,也许您对此有一些疑问。会话在哪里创建的?会话存储在什么数据结构中?接下来,让我们看看会话是如何管理的。

会话在容器中管理。什么是容器?Tomcat、Jetty等。是容器。接下来,我们以最常用的Tomcat为例,看看Tomcat是如何管理Session的。ManageBase中的CreateSession用于创建会话。

至此,我们了解了会话是如何创建的。创建后,会话将保存在ConcurrentHashMap中。可以看看StandardSession类。

protected Map<string, session> sessions = new ConcurrentHashMap<>();

至此,大家对Session应该有了一个简单的认识。

& gt会话存储在Tomcat的容器中,所以如果有多台后端机器,它就不能在多台机器之间共享。这时可以使用Spring提供的分布式会话解决方案,将会话放在Redis中。

代币

Session是将待验证的信息存储在服务器中,并与SessionId和数据相对应。SessionId由客户端存储,请求时SessionId也随之带来,因此实现了相应的状态。在服务器端对用户信息进行Base64Url编码后,令牌被传输到客户端。每次用户请求的时候,都会附带这条信息,所以服务器得到这条信息并解密后,就知道用户是谁了。这种方法被称为JWT(Json Web Token)。

& gt与Session相比,Token的优势在于当有多个后端系统时,客户端访问时直接携带数据,不需要共享数据。

令牌的优势

简洁:可以通过URL,POST参数或者是在HTTP头参数发送,因为数据量小,传输速度也很快自包含:由于串包含了用户所需要的信息,避免了多次查询数据库因为Token是以Json的形式保存在客户端的,所以JWT是跨语言的不需要在服务端保存会话信息,特别适用于分布式微服务

JWT的结构

实际的JWT大约和下面的一样长。这是一个很长的字符串,用..

JW由三部分组成

页眉

是一个描述JWT元数据的Json对象,通常如下所示

{ "alg": "HS256", "typ": "JWT"}

上面的代码中,alg属性表示签名的算法,默认为HMAC SHA256(写成HS 256);Typ属性表示这个令牌的类型,JWT令牌统称为JWT。最后,使用Base64URL算法将上面的JSON对象转换成一个字符串。

& gt作为令牌,JWT在某些情况下可能会放在URL中(比如api.example.com/?令牌=xxx)。Base64有三个字符+、/和=,在URL中有特殊含义,所以应该替换:=省略,+替换为-,/替换为_。这是Base64URL算法。

有效载荷

有效负载部分也是一个Json对象,用于存储要传输的实际数据。JWT官方规定了以下供选择的官方字段。

iss (issuer):签发人exp (expiration time):过期时间sub (subject):主题aud (audience):受众nbf (Not Before):生效时间iat (Issued At):签发时间jti (JWT ID):编号

当然,除了这些官方字段,我们也可以定义自己的私有字段。这里有一个例子。

{ "name": "xiaoMing", "age": 14}

默认情况下,JWT是不加密的,任何人只要在网上进行Base64解码就可以读取信息,所以一般不要把秘密信息放在这个部分。这个Json对象也将使用Base64URL算法转换成一个字符串。

签名

签名部分对前两部分的数据进行签名,防止数据被篡改。

首先,您需要定义一个密钥。这个密钥只有服务器知道,不能泄露给用户。然后,使用报头中指定的签名算法(默认为HMAC SHA256),在计算签名后,可以将报头、有效载荷和签名拼成一个字符串。每个部分由。并且它可以被返回给用户。

& gtHS256可以使用单个密钥为给定的数据样本创建签名。当消息与签名一起传输时,接收者可以使用相同的密钥来验证签名是否与消息匹配。

如何在Java中使用Token

上面我们已经介绍了一些关于JWT的概念。接下来怎么用?首先,将Jar包引入项目。

compile('io.jsonwebtoken:jjwt:0.9.0')

然后编写如下代码

找到的令牌如下

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdWJqZWN0IiwiaXNzIjoiaXNzdWVyIiwibmFtZSI6InhpYW9NaW5nIiwiYWdlIjoxNH0.3KOWQ-oYvBSzslW5vgB1D-JpCwS-HkWGyWdXCP5l3Ko

这时候你在网上随便找个Base64解码网站就可以解码信息了。

摘要

相信看到这里你应该对Cookie、Session、Token有所了解。我们来复习一下重要的知识点。

Cookie是存储在客户端的Session是存储在服务端的,可以理解为一个状态列表。拥有一个唯一会话标识SessionId。可以根据SessionId在服务端查询到存储的信息。Session会引发一个问题,即后端多台机器时Session共享的问题,解决方案可以使用Spring提供的框架。Token类似一个令牌,无状态的,服务端所需的信息被Base64编码后放到Token中,服务器可以直接解码出其中的数据。

大家喜欢,转发,关注三联,私信回复“马冬梅”,就可以获得相关源代码。

0