关于前端:CookieToken和Session那么美妙

5次阅读

共计 3623 个字符，预计需要花费 10 分钟才能阅读完成。

原创申明，转载请注明文章链接起源、作者信息

三个好基友~

hello，我是索奇~

精心写了一篇 Cookie、Session 和 Token 的 vivid 文章，并分享给大家

咱们能够把 Cookie、Token 和 Session 看作是三个好基友，它们都是用来跟踪用户的身份和状态的，然而它们之间有一些区别和应用场景。

Cookie

Cookie：曲奇饼，小甜饼；……样的人；（浏览网页后存储在计算机的）缓存文件；< 苏格兰 > 淡面包；丑陋的女孩

啊，不是让你翻译~ 是让你介绍计算机中 Cookie~（不过也学会了一个单词）

Cookie 就像是你的小秘书，它的次要作用是保留用户的偏好和浏览历史。比如说，你在网上买了一件衣服，然而还没决定是否买下，这时候你能够把这件衣服放进购物车，Cookie 就会帮你记住这个购物车里有什么。等到你下次再来这个网站的时候，Cookie 就会帮你把购物车里的货色显示进去，让你能够持续购物。

Cookie 的数据存储在客户端的浏览器中，不会占用服务器的资源

在浏览器的控制台中，能够间接输出：document.Cookie 来查看 Cookie。Cookie 是一个由键值对形成的字符串，出于平安思考

httponly 类型的获取不到的，不要找半天 httponly 发现找不到

又多一个名词，再摸索一下？

httponly 又是什么啊？

HttpOnly 就是一个设置在 HTTP 响应头中的标记，它能够避免某些类型的客户端脚本（如 JavaScript）拜访 cookie。当服务器向客户端发送带有 HttpOnly 标记的 cookie 时，客户端的 JavaScript 代码将无奈通过 document.cookie 拜访该 cookie，这能够无效地进步 Web 应用程序的安全性。

如果给某个 cookie 设置了 httponly 属性，则无奈通过 JS 脚本读取到该 cookie 的信息，但还是能通过 Application 中手动批改 cookie, 所以只是在肯定水平上能够避免 XSS 攻打，但也不是相对的平安

Cookie 次要用于跟踪用户的偏好和行为，以便提供个性化的体验。例如，在网站上保留用户的登录状态、购物车信息等。

啊，平时刷视频、逛 tb、个性化广告等等的信息竟然就是这样被页面记录、推送的

还有一个大家都在探讨（七嘴八舌）的话题就是 - 咱们平时的浏览记录等信息会被记录吗？

答案是不确定（不保障肯定不被记录，不保障肯定被记录）

Cookie 自身是存储在客户端的，而不是服务器端，所以服务器不须要把

Cookie 记录保留到数据库中

但至于记录集体的喜好、浏览记录等信息是否被记录到数据库，如何被记录到数据库，这取决于具体的软件、网站、隐衷政策和数据收集形式..

Session

Session 就像是你的个人档案，它的次要作用是保留用户的状态和权限。比如说，你在网站上登录之后，服务器就会为你创立一个 Session，外面保留了你的登录状态和购物车信息等等。这样，当你在浏览网站的时候，服务器就会依据 Session 来提供个性化的体验，比方显示你的购物车里有什么，或者显示你最近浏览过的商品。

也能够了解为是一个比拟非凡的 map，除了能够像其它 map 一样存取数据，它还有过期工夫、惟一的 id 辨别不同 session，

创立该 session 时，会同时创立一个 Cookie，Cookie 的 key 为JSESSIONID，而 Cookie 的 value 是该 session 的 id。

又遇到不懂的了吗？Cookie 的 key 是啥货色？

JSESSIONID是一种用于在客户端和服务器端之间传递会话信息的 Cookie 名称。当用户在浏览器中拜访一个须要登录的网站时，服务器会

在后盾创立一个会话，并生成一个惟一的 Session ID，将其存储在服务器端的 Session 中，同时，服务器会将 Session ID 通过 Cookie 的形式发送给客户端，通常应用的 Cookie 名称就是 JSESSIONID

Session 的数据信息寄存在服务器上，Session 的数据只能被服务器拜访，因而相对来说比拟平安，然而须要占用服务器的资源，
Session 次要用于跟踪用户的状态和权限，以便提供个性化的体验。例如，你搜寻的内容、在网站上保留用户的登录状态、购物车信息等。
对于 Session 并没有下限，但出于对服务器端的性能思考，Session 内不要寄存过多的货色

Token

Token 就像是你的身份证，它的次要作用是用于身份验证和受权。比如说，你在应用某个 APP 的时候，须要登录能力应用一些性能，这时候 APP 就会颁发给你一个 Token（令牌），你须要在每个申请中携带这个 Token，服务器会通过验证 Token 来确定你的身份和权限，以确保你只能拜访你有权拜访的内容。

比方用户曾经登录了零碎，我给他发一个 token，里边蕴含了这个用户的 user id，下一次这个用户再次通过 Http 申请拜访我的时候，把这个 token 通过 Http header 带过去就能够了。

然而这时候感觉和 session 没区别啊，万一有人伪造做假攻打呢？于是就用算法对数据做了签名，用签名 + 数据 = token，签名不晓得，也就无奈伪造 token 了

这个 token 不保留，当用户把这个 token 给我发过去的时候，我再用同样的算法和同样的密钥，对数据再计算一次签名，和 token 中的签名做个比拟，如果雷同，我就晓得用户曾经登录过了，并且能够间接取到用户的 user id , 如果不雷同，数据局部必定被人篡改过，就晓得这个人是冒充货，返给它没有认证的信息

Token 是一种无状态的身份验证机制，意味着服务器不须要保留 Token 的状态（这不是大大的加重了服务器的压力~），前后端拆散架构中前端无奈间接拜访后端的 Session。然而，前后端拆散架构中仍然能够应用 Session 来存储应用程序的其余状态信息，例如购物车数据等，只是不能用来保留用户的登录状态。

既能够保留在服务器也能够在客户端
Token 是一种无状态的身份验证机制，它能够在多个服务器之间共享，而 Session 则须要在每个服务器上都保留一份。应用 Token 能够防止 Session 共享和 Session 过期等问题，同时也能够升高服务器的累赘。
Token 中的数据是明文保留的, 还是能够被他人看到的，所以我不能在其中保留像明码这样的敏感信息
基于 Token 的身份验证是无状态的，咱们不将用户信息存在服务器或 Session 中。
大多数应用 Web API 的互联网公司中，它是 Tokens 多用户下解决认证的最佳形式
被攻打是不是很懊恼！Token 通常用于 API 身份验证等场景，能够无效防止跨站申请伪造（CSRF）等攻打~

拓展一下 Token 的身份验证过程

用户在客户端进行登录操作，将用户名和密码发送到服务器端。
服务器端通过验证用户名和明码的正确性，生成一个 Token，并将 Token 返回给客户端。
客户端将 Token 保留在本地，例如在浏览器的 Cookie 或 localStorage 中。
客户端在后续的申请中，将 Token 发送给服务器端进行身份验证。
服务器端接管到申请后，从申请中获取 Token，并对 Token 进行解密和验证。
如果 Token 验证通过，服务器端将响应申请并返回所需的数据，否则返回身份验证失败的错误信息。

在身份验证过程中，服务器端通常会对 Token 进行解密、验证签名、查看 Token 是否过期等操作，以确保 Token 的有效性和安全性

栩栩如生、通俗易懂~ 重点讲完了！

简略记一些常识

看完了没，啥也没懂？好吧，无奈，简略记一下区别吧，面试时候不能理屈词穷吧

Session 和 Token 是在服务器端保留数据的机制，而 Cookie 是在客户端保留数据的机制

通常状况单个 Cookie 保留的数据在 4KB 以内（面试官：这都晓得，给你 offer！悲痛欲绝的本人：太好了！）
Session 和 Token 通常用于身份验证和状态治理，而 Cookie 通常用于跟踪用户的偏好和行为
Session 和 Token 通常用于敏感数据的存储和传输，而 Cookie 通常用于非敏感数据的存储和传输。
Session 和 Token 须要服务器端进行治理和保护，而 Cookie 能够由客户端自行治理和保护。
Token 能够跨域应用，而 Session 通常只能在同一个域名下应用；Token 能够在分布式系统中应用，而 Session 通常只能在繁多服务器上应用。

（能够疏忽）写着写着又想要拓展了，哈哈哈，想要摸索的搭档们，肯定想要晓得单个站点能够存储的 Cookie 数量，

这里有纳闷？

国内互联网规范是每个网站能够存储的 Cookie 数量不得超过 300 个，具体还是依据不同的浏览器来定，

发现局部博主说单个站点最多保留 20 个 Cookie，这是不合理的，也有近 100 点赞

网上一连串的信息是复制的，有时咱们不能轻易的置信，要学会本人去摸索，去验证！不然就误人耳目了

这里是仅仅是为了阐明下 Cookie 的数量，帮忙更多搭档学会摸索常识，对原博主没有任何歹意哈

正文完