cookie session token

最近有个登录认证的需求, 就去搜查了下相关技术理念, 发现网上很多人对于标题中的这三个玩意儿并没有达成很一致的共识, 也就是说概念理解各有偏差. 所以经过一阵搜索逛论坛逛社区, 准备总结一下, 可能会有偏差, 望指正(鞠躬)

这三个大致都是一个作用:

让服务器端能知道请求的是谁, 以对应相应状态(比如用户已登录或用户不存在)

为什么产生:

HTTP是无状态的

cookie

状态保存在客户端, 或与服务器端合作

最没有, 或者说最少争议的, 定义最明确, 理解最统一的就是cookie了, 小饼干, 名字很cute.

直接来看标准, RFC2109 => RFC2965 => RFC6265, 看最新的:HTTP State Management Mechanismtools.ietf.org

cookie的实质:

http头里的字段, 键值对形式, 或是单个的一个值

Set-Cookie 提供给服务器, 发送给用户, 用以设置cookie(服务器递过来一袋小饼干)
Cookie 用户请求服务器时携带cookie(服务器, 看! 这是我的小饼干)

从格式上来讲很简单: 键值对, 分号隔开

有一些专用的键值, 用以控制cookies的行为, 比如:

Expires 过期日期
Max-age 存活时间
Domain 对应的域, 可以设置以供多个同域名主机共享cookie, 或限制cookie可使用的域
Path 控制哪些路径的页面可以访问cookie
Secure 可以http传输或只能https, 防中间人攻击
HttpOnly 设置以禁用js的Document.cookie

API, 防XSS

cookie的使用:

传统地, 把一些简单的用户信息存储在cookie里, 浏览器存cookie有大小数量限制:

At least 4096 bytes per cookie (as measured by the sum of the
length of the cookie’s name, value, and attributes).
At least 50 cookies per domain.
At least 3000 cookies total.

日常使用么, 自动登录什么的, 账号密码存cookie, 然后前端js里去判断cookie里有没有账号密码, 有就自动帮你填了提交, 免得你费力.

session

状态保存在服务器端

session这个东西就不是很清晰的一个实体了, 是一个抽象概念. 这实际是一种理念, 或者说是模式方法, 用来保存认证用户信息.

翻译过来是”会话”, 指代session这一模式, 当然也可能指代具体的数据库里保存的用户信息, 容易搞混, 这里指的是这种模式.

怎样一种模式呢?

服务器端存储用户数据信息. 这么多用户想要知道谁是谁, 每个必须有个名字, 或者说是id, 所谓”session id”(你可能看到过这个叫法). 用户先请求, 然后服务器生成session id(如果用户没有携带, 或已过期)并返还给用户, 用户留着, 以后每次请求, 带上这个”session id”, 然后服务器拿来往数据库(或者放内存, 这个视具体应用而定)里一搜, 找到该用户及其相应的信息(有时session id集中存放, 与数据分开, 用户数据分开放在集群里), 比如: 现在对应的用户是登录状态还是超时登出了什么的.

状态信息存储在服务器端, 用户只需留存一个”session id”. 大多数时候通过cookie传递存放, 当然也可以ajax传, 存Local Storage或Session Storage或IndexDB或Web SQL, 反正只要用户拿到并存着就行, 甚至可以用URL重写的方式传递.

所以说session是一种模式.

当然问题不少, 比如使用集群时怎么同步数据的问题, 像刚才括号里说的session id集中存放, 万一集中存的数据出事了怎么办, 等等, 但session用的还是很广泛的.

token

相较于前两个, token一般用于短期的验证

token翻译过来是”令牌”

token是服务器在用户登录后返还给用户的

token是无状态的, 用以在一段时间内免于重复登录, 过了时间就失效

怎么理解token, 我们来对登录这件事进行一个逻辑上的抽象: