详解基于Session-Cookie的认证机制

由于 HTTP协议是无状态的，所以为了能让服务器知道用户当前所处的状态，就需要存储一些信息在当前用户访问的浏览器中，并且需要在下次请求时发送到服务器端，而存储的这些信息就是Cookie；Cookie的意思就是小饼干，就是小而甜的意思。

Cookie的特性

Cookie是不能跨浏览器的，也就说你使用Goole浏览器产生的Cookie信息，IE浏览器是访问不到的

每个浏览器都会限制存储Cookie的个数，像FireFox就限制最多有50个Cookie，单个Cookie文件的大小限制为4KB

由于同源策略的限制（ 协议，域名，端口相同则为同源 ），所以Cookie也有两个参数来设置Cookie的作用域：

• Domain：设置 Cookie可以被那些域名获取到
• Path：设置可以访问Cookie的路径

浏览器提交Cookie需要满足如下的两个条件：

1. 是当前域名和或者父域名的Cookie
2. 是当前路径或者父路径的Cookie

满足上面两个条件的Cookie才能被发送到服务器端，下面举个例子，来说明下Cookie的作用域：

Cookie1:[name=value,domain=.wisepass.com,path=/]
Cookie2:[name=value,doamin=www.wisepass.com,path=/order]
Cookie3:[name=value,domain=www.wisepass.com,path=/]
Cookie4:[name=value,doamin=exmaple.wisepass.com,path=/]

上面列出来四个Cookie，下面来看下www.wisepass.com能获取到那些Cooki:

1. Cookie1可以获取到，因为 Cookie1的domain是当前这个域名的父域，Path 的路径也一致
2. Cookie2获取不到，虽然他们的域名相同，但是Cookie2的Path是它的子路径而不是父路径
3. Cookie3可以获取到，他们的域名和路径都一致
4. Cookie4 获取不到，因为domain不一致，也不是它的父域名

Session

Session就是会话的意思，也就是客户端访问服务器之后就会和服务器建立一种Session（会话的）关系，当客户端下次访问时就能知道当前这个客户端是谁了

相较于Cookie而言，Session是存储在服务器端的。客户端首次请求时，就会生成一条Session记录，存储在服务器端，同时为这条Session记录生成唯一的SessionID通过SetCookie返回到客户端存储起来，之后客户端再次请求时，服务端通过 Cookie拿到SessionID可以判断客户端身份了

已经有了Cookie了，那为什么还需要Session呢？是因为Cookie其实有很多的限制的，每种浏览器存储Cookie都会有大小限制；Cookie是存储在客户端的所以很容易被篡改；每次发送请求时都会带着Cookie所以一些敏感信息不方便存储在Cookie中；还有就是Cookie有同源限制的问题；所以将一些用户的登录信息存储在Session中比较方便，安全；

Session-Cookie 认证机制

1. 用户输入登录信息
2. 服务器验证登录信息，如果正确，则生成 session 信息，并且存储到 Redis 中
3. 服务端为当前的 Session 信息生成一个唯一的标识 SessionID，然后放入的 Response Header中的 SetCookie中
4. 浏览器收到响应后就会把Cookie存起来，当下次请求时，浏览器会自动带上该Cookie
5. 服务端从 Request Header解析 Cookie获取到 SessionID，然会通过此 SessionID获取保存在服务器端的Session信息进行权限校验
6. 当然当浏览器退出登陆时，浏览器端的Cookie和服务器端的Session都会被清除调

基于 Session - Cookie 认证的优缺点

session-cookie 认证机制在基本上所有的网页浏览器上都能够支持，而且实现方式也很简单

1. 当存在多台服务器时会出现 session同步问题
2. 很容易遭受到 Cookie 欺骗和 CRFS攻击
3. 服务端存储压力，当很多的session存储到服务端时，会对服务器的存储造成压力
4. 跨域问题，Cookie是属于同源策略限制的条件之一