爬虫教程 - 模拟登录的基本原理

1. 网站登录验证的实现
   我们要实现模拟登录，那就得首先了解网站登录验证的实现。

登录一般是需要两个内容，用户名和密码，有的网站可能是手机号和验证码，有的是微信扫码，有的是 OAuth 验证等等，但根本上来说，都是把一些可供认证的信息提交给了服务器。

比如这里我们就拿用户名和密码来说吧。用户在一个网页表单里面输入了这些内容，然后点击登录按钮的一瞬间，浏览器客户端就会向服务器发送一个登录请求，这个请求里面肯定就包含了用户名和密码信息，这时候，服务器需要处理一下这些信息，然后返回给客户端一个类似「凭证」的东西，有了这个「凭证」以后呢，客户端拿着这个「凭证」再去访问某些需要登录才能查看的页面，服务器自然就能” 放行 “了，返回对应的内容或执行对应的操作就好了。

形象点说呢，我们拿登录发微博和买票坐火车这两件事来类比。发微博就好像要坐火车，没票是没法坐火车的吧，要坐火车怎么办呢？当然是先买票了，我们拿钱去火车站买个票，有了票之后，进站口查验一下，没问题就自然能去坐火车了，这个票就是坐火车的「凭证」。那发微博也一样，我们有用户名和密码，请求下服务器，获得一个「凭证」，这就相当于买到了火车票，然后在发微博的时候拿着这个「凭证」去请求服务器，服务器校验没问题，自然就把微博发出去了。

那么问题来了，这个「凭证」到底是怎么生成和验证的呢？目前比较流行的实现方式有两种，一种是基于 Session + Cookie 的验证，一种是基于 JWT（JSON Web Token）的验证，下面我们来介绍下。

2. Session 和 Cookie
   我们在第一章了解了 Session 和 Cookie 的基本概念。简而言之呢，Session 就是存在服务端的，里面保存了用户此次访问的会话信息，Cookie 则是保存在用户本地浏览器的，它会在每次用户访问网站的时候发送给服务器，Cookie 会作为 Request Headers 的一部分发送给服务器，服务器根据 Cookie 里面包含的信息判断找出其 Session 对象并做一些校验，不同的 Session 对象里面维持了不同访问用户的状态，服务器可以根据这些信息决定返回 Response 的内容。

我们以用户登录的情形来说吧，其实不同的网站对于用户的登录状态的实现是可能不同的，但是 Session 和 Cookie 一定是相互配合工作的。

下面梳理如下：

比如说，Cookie 里面可能只存了 Session ID 相关信息，服务器能根据 Cookie 找到对应的 Session，用户登录之后，服务器会把对应的 Session 里面标记一个字段，代表已登录状态或者其他信息（如角色、登录时间）等等，这样用户每次访问网站的时候都带着 Cookie 来访问，服务器就能找到对应的 Session，然后看一下 Session 里面的状态是登录状态，那就可以返回对应的结果或执行某些操作。
当然 Cookie 里面也可能直接存了某些凭证信息。比如说用户在发起登录请求之后，服务器校验通过，返回给客户端的 Response Headers 里面可能带有 Set-Cookie 字段，里面可能就包含了类似凭证的信息，这样客户端会执行设置 Cookie 的操作，将这些信息保存到 Cookie 里面，以后再访问网页时携带这些 Cookie 信息，服务器拿着这里面的信息校验，自然也能实现登录状态检测了。
以上两种情况几乎能涵盖大部分的 Session 和 Cookie 登录验证的实现，具体的实现逻辑因服务器而异，但 Session 和 Cookie 一定是需要相互配合才能实现的。

3. JWT
   Web 开发技术是一直在发展的，近几年前后端分离的趋势越来越火，很多 Web 网站都采取了前后端分离的技术来实现。而且传统的基于 Session 和 Cookie 的校验也存在一定问题，比如服务器需要维护登录用户的 Session 信息，而且分布式部署不方便，也不太适合前后端分离的项目。

所以，JWT 技术应运而生。

JWT，英文全称为 JSON Web Token，是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准。实际上就是在每次登录的时候通过一个 Token 字符串来校验登录状态。JWT 的声明一般被用来在身份提供者和服务提供者之间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的业务逻辑所必须的声明信息，所以这个 Token 也可直接被用于认证，也可传递一些额外信息。

有了 JWT，一些认证就不需要借助于 Session 和 Cookie 了，服务器也无须维护 Session 信息，减少了服务器的开销。服务器只需要有一个校验 JWT 的功能就好了，同时也可以做到分布式部署和跨语言的支持。

JWT 通常就是一个加密的字符串，它也有自己的标准，类似下面的这种格式：

eyJ0eXAxIjoiMTIzNCIsImFsZzIiOiJhZG1pbiIsInR5cCI6IkpXVCIsImFsZyI6IkhTMjU2In0.eyJVc2VySWQiOjEyMywiVXNlck5hbWUiOiJhZG1pbiIsImV4cCI6MTU1MjI4Njc0Ni44Nzc0MDE4fQ.pEgdmFAy73walFonEm2zbxg46Oth3dlT02HR9iVzXa8
我们可以发现中间有两个用来分割的 . ，因此可以把它看成是一个三段式的加密字符串。

它由三部分构成，分别是 Header、Payload、Signature。

Header，声明了 JWT 的签名算法，如 RSA、SHA256 等，也可能包含 JWT 编号或类型等数据，然后对整个信息进行 Base64 编码即可。
Payload，通常用来存放一些业务需要但不敏感的信息，如 UserID 等，另外它也有很多默认是字段，如 JWT 签发者、JWT 接受者、JWT 过期时间等，Base64 编码即可。
Signature，就是一个签名，是把 Header、Payload 的信息用秘钥 secret 加密后形成的，这个 secret 是保存在服务器端的，不能被轻易泄露。如此一来，即使一些 Payload 的信息被篡改，服务器也能通过 Signature 判断出非法请求，拒绝服务。