为什么需要登录
HTTP是一种无状态的协议,客户端每次发送请求时会与服务器建立一个连接,请求之后断开连接。因此每次请求都是独立的,服务器无法判断每次请求是否是来自同一个用户。所以登录是为了让服务器在多次请求之间能识别出用户。
实现登录的思路
暂时抛开具体的技术不谈,我们先思考一下登录的实现。
以用户名密码登录为例,用户输入的用户名、密码校验成功后,登录成功。那么如何知道后续的请求都来自这个用户呢?考虑到HTTP的无状态性,后面的每次请求都应该带上一个能唯一识别用户的标识。
如果这个标识是单纯的用户名+密码
,我们有两种实现思路:一种是每次都让用户输入用户名密码,这样虽然安全,但显然会造成极差的用户体验,因此舍掉。另一种是将用户名密码存储在某个位置,每次请求时自动带上,这样虽然方便,但直接存储用户名密码显然很容易被盗取,毫无安全性可言。
因此,我们想到用另一个标识代替用户名密码。这个标识最好是谁都看不懂的那种,而且它必须不重复,每个人拥有的标识都是独一无二的。由此一来,又引发出三个问题:
- 这个标识从哪来?
- 客户端怎么将标识传给服务端?
- 服务端该如何验证这个标识?
为了解决这三个问题,引入如下技术,这也是目前业界通用的登录方案:
Cookie + Session
根据该技术的实现方案,依次回答上面三个问题:
-
这个标识从哪来?
用户首次登录成功后,服务端会生成一个
sessionId
,这个sessionId
就是唯一标识。这里的sessionId
由我们指定的算法生成。因此这个标识由服务端生成,然后通过设置头Set-Cookie
在客户端存储。 -
客户端怎么将标识传给服务端?
客户端从服务端拿到
cookie
,在之后的每次请求都带上这个cookie
,cookie
中存储的就是这个标识。 -
服务端该如何验证这个标识?
服务端在生成
sessionId
的同时也存储了sessionId
与用户信息的映射关系。因此在验证标识的时候,会从映射关系表中查找这个sessionId
,如果找到了就验证成功,并拿到用户信息,否则验证失败。