这篇文章主要介绍“Node学习之聊聊Cookie-Session登录验证的工作原理”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“Node学习之聊聊Cookie-Session登录验证的工作原理”文章能帮助大家解决问题。

目前成都创新互联已为千余家的企业提供了网站建设、域名、网页空间、网站托管、服务器托管、企业网站设计、略阳网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。

1️⃣ Cookie&Session

我们知道，HTTP 是无状态的。也就是说，HTTP 请求方和响应方间无法维护状态，都是一次性的，它不知道前后的请求都发生了什么。但有的场景下，我们需要维护状态。最典型的，一个用户登陆微博，发布、关注、评论，都应是在登录后的用户状态下的。

这个时候就可以引入Cookie与Session来保存用户的登录状态。

为什么不单独使用Cookie？

Cookie是存放在浏览器中的，可以在浏览器中打开控制台，选择应用，找到存储中的Cookie进行查看：

当客户端向服务端发送网络请求时浏览器会自动将Cookie添加到请求头中，这样服务端就能获取这个Cookie，如下：

知道了这个原理后，我们就可以想到，如果在用户登录系统时：客户端由用户的部分登录信息（比如username、id等）生成一个Cookie存放到浏览器中，那么在这之后的每一次网络请求都会自动携带上该Cookie。

之后让服务端根据请求中是否携带Cookie并且携带的Cookie中是否存在有效的username、id来判断用户是否已经登录过了，这样一来用户的登录状态不就被保存下来了吗。

回到上面我们提到的微博的例子，按照这种过程来说，当用户登录过后Cookie已经被保存，这时当用户进行发布、关注、评论等需要登录才能使用的操作时我们就能提前判断是否存在Cookie，如果存在并且Cookie中含有该用户的id，那么我们就可以允许该用户的这些操作（这些操作一般都是需要用户的id的，这时就可以从Cookie中进行获取）。相反的，如果Cookie不存在或者Cookie无效，那么就禁止该用户的这些操作。

说到这，你可能会问：既然一个Cookie就能实现我们想要的效果，那为何还要使用Session呢？

这是因为 Cookie很容易被伪造！ ，如果我们知道了Cookie中存放的信息是username和id（就算不知道，也可以在登录后的网络请求的请求体中找到Cookie），那么我们完全可以在不登录的情况下手动向浏览器存储一个伪造的Cookie：

说到这，你应该就能明白为什么不能单独使用Cookie了吧。

Session是如何与Cookie结合的？

Session其实是基于Cookie实现的，并且Session存储在服务端的内存或者数据库中。

当用户登录成功时，使用Cookie&Session的登录验证会进行以下操作：

• 由服务端生成Session与SessionId；

  Session一般是根据用户登录的信息，如用户名、id等进行生成。
  如果把Session比作是一把锁，那么SessionId就相当于是这把锁的钥匙。

• 服务端将Session存储到内存或者数据库中；

• 服务端将SessionId存放到请求的响应头（response对象）中的Set-Cookie字段中发送给客户端；

• 客户端收到Set-Cookie后会自动将Set-Cookie的值（也就是SessionId）存放到Cookie中；

• 之后的每次网络请求都会自动带上Cookie，也就是带上这个SessionId；

• 服务端收到后续请求时获取请求上的Cookie，也就是获取到了SessionId，然后通过SessionId查询并校验服务端存储的Session，若校验成功说明这个SessionId有效则通过此次请求，反之则阻止此次请求。

图示：

2️⃣ Cookie&Session的缺陷

存储问题

为了保存用户的登录状态，我们需要为每一位登录的用户生成并存储Session，这势必就会造成以下问题：

• 如果Session存放到内存中，那么当服务端重启时，这些内存中的Session都将被清除，那么所有用户的登录状态都将会过期，并且当用户量较大时，过多的内存占用也势必会影响服务端的性能。

• 如果Session存放到数据库中，虽然能够解决因服务端重启造成用户登录状态过期的问题，但当用户量较大时，对于这个数据库的维护也会变得相对困难。

• 如果前端页面中调用的接口来自两个服务器（也就是两套数据库），为了实现Session在两个服务器间共享通常会将Session存放到一个单独的数据库中，这样就使得整个项目变得更为复杂也更加难以维护。
  

CSRF问题

CSRF全称为 Cross-site request forgery 即 跨站请求伪造，使用Cookie进行验证的网站都会面临或大或小的CSRF威胁，我们以一个银行网站的例子来介绍CSRF的攻击原理：

假如一家银行网站A的登录验证采用的是Cookie&Session，并且该网站上用以运行转账操作的Api地址为：http://www.grillbankapi.com/?account=AccoutName&amount=1000

api参数：account代表账户名，amount代表转账金额。

那么，一个恶意攻击者可以在另一个网站B上放置如下代码：

注意：img标签的src是网站A转账操作的api地址，并且参数account为Ailjx，amount为1000，也就是说这个api地址相当于是账户名为 Ailjx 转账1000 时调用的api。

如果有账户名为 Ailjx 的用户刚访问过网站A不久，登录信息尚未过期（网站A的Cookie存在且有效）。

那么当 Ailjx 访问了这个恶意网站B时，上面的img标签将被加载，浏览器就会自动请求img标签的src路由，也就是请求http://www.grillbankapi.com/?account=Ailjx&amount=1000 （我们将这个请求记为请求Q），并且因为Cookie存放在浏览器中且浏览器发送请求时会自动带上Cookie，所以请求Q上就会自动携带 Ailjx 在网站A上的Cookie凭证，结果就是这个 请求Q将会被通过，那么 Ailjx 就会损失1000资金。

这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。 此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着如果服务端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。

透过例子能够看出，攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户浏览器，让其以用户的名义运行操作。

这些就是使用Cookie&Session来做登录验证的问题所在，那么我们如何解决这些问题呢？这就需要引入JWT的概念，使用token来做登录验证，这些我们将在之后的文章中进行讲解。

关于“Node学习之聊聊Cookie-Session登录验证的工作原理”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识，可以关注创新互联行业资讯频道，小编每天都会为大家更新不同的知识点。

文章题目：Node之Cookie-Session登录验证的工作原理是什么
文章来源：http://pwwzsj.com/article/pipcpg.html