Session

245次阅读

共计 42 个字符,预计需要花费 1 分钟才能阅读完成。

第 5 节 Session 快速入门

第 6 节 Session 细节

第 7 节 Session 之验证码案例

正文完
 0

session

245次阅读

共计 1960 个字符,预计需要花费 5 分钟才能阅读完成。

1. 概念:

  • 是一个数据对象,用来存储信息。
  • 是一个抽象对象,指代多个有关联的 http 请求所构成的一个会话。多次请求之间能够共享一些信息。

2. 实现方案:

  • 方案 1:在每个请求的参数或者数据中带上相关的信息。不受 cookie 限制,但是受到 请求长度的限制。
  • 方案 2:用 cookie 存储,可以是整个 session 的具体数据,也可以是 session 的标识(sessin_id).

3. 特点:

  • 只存在于 服务端。
  • 并不是 服务器 原生支持的。是中间件自己创建并管理的。
  • session 仅仅是一个对象信息,可以存到 cookie,也可以存到任何地方(如内存,数据库)。
  • 存到哪,可以开发者自己决定。
  • session_id,是唯一的标识 session 的,以及其他一些必要信息会放在 cookie 中,一起返回到前端。
  • 其他信息,可以保存在 session_id 命名的文件中。

4. session 的负面影响:

  • 性能影响。如果用户很多,信息都保存在 sessin 文件中,查找耗时太多(可以分目录和哈希等)。
  • 可以自己实现 session,将 session 信息存放到 数据库当中,这样做最好对数据库进行一下缓存的设置了,不然对上千万的数据进行太频繁的检索,也是蛮耗资源的。

5. session 的清除:

  • 定期清理 session(清除服务端的 session 文件,和 客户端的 cookie 信息)
  • cookie,expires 设置为 过去的时间 /max-age = 0,客户端的 cookie 信息就会过期,浏览器就会自动删除。

6. koa-session 的 原理:【有空一定要看看源码,看源码要注意命名、特色、知识点的学习。也会学习 koa 插件的写法的过程】【看源码,要先有整体把控图,然后逐步去分析啊】

  • 使用流程:

    • app.use(session(CONFIG, app)); // 初始化 koa-session 中间件
    • let n = ctx.session.views || 0; // 每次都可以取到当前用户的 session
  • 初始化的时候,把 session 对象挂载在 app.context 上。所以后面可以 从 ctx.session 上获得 session
  • 在接到 http 请求的时候,
  • 默认把数据 json,塞进了 cookie,即 cookie 来存储加密后的 session 信息。
  • 如果设置了外部 store,会调用 store.set() 去保存 session。具体的保存逻辑,保存到哪里,由 store 对象自己决定!
  • 用 cookie 存储的时候,对 session(包含过期时间)序列化后做一个简单的 base64 编码。
  • 就算信息保存在文件中,还是必不可少的需要 cookie
  • session_id 的默认实现是 一个时间戳加随机字符串。
  • koa-session 允许用户在 config 中配置自己的编码和解码函数,因此完全可以使用自定义的加密解密函数对 session 进行编解码

7. session 的鉴权过程:

  • 用户登录的时候,服务端生成一个会话和一个 id 标识
  • 会话 id 在客户端和服务端之间通过 cookie 进行传输
  • 服务端通过会话 id 可以获取到会话相关的信息,然后对客户端的请求进行响应;如果找不到有效的会话,那么认为用户是未登陆状态
  • 会话会有过期时间,也可以通过一些操作(比如登出)来主动删除

8. 分布式 session:

  • 问题:分布式环境下,前后访问的服务器不同,所以导致 session 不能准确保存

    • 解决方案:将 session 信息放在一个独立的机器上(可以是一个独立的数据库服务,也可以是一个缓存服务)
    • 缺点:但是这个持久层一旦挂了,就会单点失败。
    • 新方案:索性不保存 session 数据,所有数据保存在客户端,每次请求都发回服务器(这就是 token)

9. cookie 和 session 的区别:

  • 存储位置不同:cookie -> 客户端浏览器。session -> 服务器
  • 隐私策略不同:cookie -> 不是很安全,cookie 劫持。session -> 相对安全
  • 性能不同:session -> 访问量太大时,占用服务器性能
  • 存储大小不同:cookie -> 有大小限制,一般不超过 4K

10. 参考:

- https://www.cnblogs.com/woodk/p/10129836.html
    - 看源码的时候,可以画一下 主要模块的脑图,更有助于理解。- https://www.cnblogs.com/longhao/p/3558871.html
- https://www.jianshu.com/p/8f4cc45d712e
- https://segmentfault.com/a/1190000013039187
- https://juejin.im/post/59d1f59bf265da06700b0934#heading-9
- https://juejin.im/post/5d01f82cf265da1b67210869#heading-11

正文完
 0

Session

249次阅读

共计 1334 个字符,预计需要花费 4 分钟才能阅读完成。

Session
Cookie 和 Session
区别与联系

由于 HTTP 协议是无状态的协议,所以服务端需要记录用户的状态时,就需要用某种机制来识具体的用户,这个机制就是 Session。典型的场景比如购物车,当你点击下单按钮时,由于 HTTP 协议无状态,所以并不知道是哪个用户操作的,所以服务端要为特定的用户创建了特定的 Session,用用于标识这个用户,并且跟踪用户,这样才知道购物车里面有几件物品。这个 Session 是保存在服务端的,有一个唯一标识。在服务端保存 Session 的方法很多,内存、数据库、文件、集群等。
服务端如何识别特定的客户?第一次创建 Session 的时候,服务端会在 HTTP 协议中告诉客户端,需要在 Cookie 里面记录一个 Session ID,以后每次请求把这个会话 ID 发送到服务器,就可以依据此来识别不同客户端了。如果客户端的浏览器禁用了 Cookie 怎么办?一般这种情况下,会使用一种叫做 URL 重写的技术来进行会话跟踪,即每次 HTTP 交互,URL 后面都会被附加上一个诸如 sid=xxxxx 这样的参数,服务端据此来识别用户。

总结:

Session 是在服务端保存的一个数据结构,用来跟踪用户的状态,这个数据可以保存在集群、数据库、文件中;
Cookie 是客户端保存用户信息的一种机制,用来记录用户的一些信息,也是实现 Session 的一种方式。

来源链接:https://www.zhihu.com/questio…
什么是 session?

服务器通过 Cookie 发送给客户端一个 sessionID
sessionID 对应服务器里的一小块内存,这里保存着用户的信息,例如登录信息,购物车信息等。
每次用户访问服务器的时候,服务器通过浏览器发送来的 cookie 里的 sessionID 去读取对应的内存里的信息,以此来知道用户的隐私信息。

注意

session 的好处是防止用户随意篡改 cookie,获取别人的信息。
如果用户随意篡改了 sessionID,那么只能重新登录。
因为 sessionID 是随机数,或者随机数夹杂着一些字母,所以没有可能暴力破解 sessionID,获取别的用户的信息。

类比:session 相当于发会员卡,会员卡上只有卡号(sessionID)。下次去健身房的时候,只要看卡号上,就能确定你本人的去他信息。而 cookie 相当于把信息都写在会员卡上了。
关于 session 的实现代码演示(nodejs)
总结
Session 与 Cookie 的关系
一般来说,Session 基于 Cookie 来实现。
Cookie

服务器通过 Set-Cookie 头给客户端一串字符串
客户端每次访问相同域名的网页时,必须带上这段字符串
客户端要在一段时间内保存这个 Cookie
Cookie 默认在用户关闭页面后就失效,后台代码可以任意设置 Cookie 的过期时间
大小大概在 4kb 以内

Session
Session(不翻译, 或翻译为会话)

将 SessionID(随机数)通过 Cookie 发给客户端
客户端访问服务器时,服务器读取 SessionID
服务器有一块内存(哈希表)保存了所有 session
通过 SessionID 我们可以得到对应用户的隐私信息,如 id、email
这块内存(哈希表)就是服务器上的所有 session

正文完
 0