Node Express Connect - 会话管理 [英] Node Express Connect - Session Management

问题描述

我为 ArangoDB for ConnectJS 编写了一个会话存储驱动程序.它正在工作，虽然仍处于 alpha 阶段，但我有几个问题.

I've written a session store driver for ArangoDB for ConnectJS. It is working, although still very much in alpha, but I have a couple questions.

具有false"属性的第一个会话仅在用户代理的持续时间内保留.我注意到 session.destroy() 在浏览器窗口关闭时没有被调用.这会导致在存储中留下一个被放弃的"会话.我怎样才能有效地清除这些?有没有办法按计划搜索和销毁废弃的会话?

First sessions that have an expires attribute of "false" only remain for the duration of the user-agent. I've noticed that session.destroy() is not called when the browser window is closed. This results in an "abandoned" session left in the store. How can I effectively clear these out? Is there a way to search for and destroy abandoned sessions on a scheduled basis?

其次，我已经实现了本页中概述的会话存储的最低要求:http://www.senchalabs.org/connect/session.html(靠近底部)

Second, I have implemented the minimum requirements for my session store as outlined on this page: http://www.senchalabs.org/connect/session.html (close to the bottom)

那将是获取、设置和销毁.另外两种推荐的方法是长度和清晰.这些方法究竟应该做什么?我假设 length 返回会话处于活动状态的时间长度?清除"与销毁有何不同?谢谢！

That would be get, set, and destroy. The other two recommended methods are length and clear. What exactly should these methods do? I assume length returns the length of time a session has been active? How is 'clear' different than destroy? Thanks!

推荐答案

除非您在客户端上设置了一些事件来通知服务器窗口正在关闭，否则服务器将无法知道会话不再使用.

Unless you rigged up some event on the client to notify the server the window is closing, the server would have no way of knowing the session is no longer used.

您想在心理上将会话视为两个部分.一部分是在节点和浏览器之间传递的令牌(cookie).第二个是会话在存储中的实际持久性(基本 MemoryStore 或 Redis，或另一个数据库的新会话存储).连接会话代码所做的就是将这些与每个请求匹配起来.

You want to mentally think about sessions as two parts. One part is the token (the cookie) that is passed between node and the browser. The second is the actual persistence of sessions in a store (either the basic MemoryStore or Redis, or your new session store for another database). All the connect session code is doing is matching these up with every request.

• 检查会话 cookie
• 如果存在，请尝试在商店中查找
• 使从商店检索到的数据可用于请求
• 在请求结束时，更新 cookie 的 TTL 信息
• 将会话写回商店

请注意，除非您使用 MemoryStore，否则 Node 不会在内存中保存会话数据，除非您的请求正在对它进行操作.(好吧，它会在内存中一段时间​​，但不会被引用并受垃圾收集的影响).当您考虑各种部署方案时，这是有道理的.

Notice that unless you are using the MemoryStore, Node doesn't have the session data in memory other than while your request is operating on it. (Well, it would be in memory for a while but would be unreferenced and subject to garbage collection). When you think about various deployment scenarios this makes sense.

因此，服务器端会话过期的工作落到了 Store 本身的肩上.Redis 非常适合这一点的原因之一是它自动管理过期的东西，你可以看到 connect-redis 做 在其设置操作中:

Thus, the job of server-side expiration of sessions falls to the Store itself. One of the reasons Redis is great for this is because it manages expiring things automatagically, which you can see connect-redis doing in its set operation:

  RedisStore.prototype.set = function(sid, sess, fn){
    sid = this.prefix + sid;
    try {
      var maxAge = sess.cookie.maxAge
        , ttl = this.ttl
        , sess = JSON.stringify(sess);

      ttl = ttl || ('number' == typeof maxAge
          ? maxAge / 1000 | 0
          : oneDay);

      debug('SETEX "%s" ttl:%s %s', sid, ttl, sess);
      this.client.setex(sid, ttl, sess, function(err){
        err || debug('SETEX complete');
        fn && fn.apply(this, arguments);
      });
    } catch (err) {
      fn && fn(err);
    } 
  };

您可以看到它将 TTL 除以 1000，因为它使用秒而不是毫秒作为其到期时间.最流行的 MongoDB Session 存储以相同的方式使用 MongoDB 的 TTL 功能.

You can see that it divides TTL by 1000 because it uses seconds rather than millis for its expiration. The most popular MongoDB Session store uses MongoDB's TTL feature in the same way.

所以这是一个很长的说法，你要么依赖你的数据库引擎自动提供服务器端会话过期，要么你需要自己实现过期.你可以在你的节点应用程序之外有一个进程(可能是另一个节点进程)来完成它，或者你的商店实现可以安装一个 SetInterval 任务来定期检查和清理它.例如，基于 MySQL 的会话存储就是这样做的

So this was a long way of saying that you will either rely on your DB engine to provide server-side expiration of sessions automatically or you need to implement expiration yourself. You could have a process outside of your node app (maybe another node process) that does it or your store implementation could install a SetInterval task to periodically check and clean it. As an example, a MySQL-based session store does just that

关于您问题的第二部分，length 和 clear 是做什么的?评论者是正确的，RedisStore 没有实现这些，它们可能可以被安全地忽略，但是你可以在 MemoryStore 源代码.不太刺激.

Regarding the second part of your question, what are length and clear doing? The commenter is correct that RedisStore doesn't implement these and they can probably be ignored safely, however you can see their implementations in the MemoryStore source code. Not too exciting.

clear 如果提供回调，则清空所有会话和回调:

clear empties all the sessions and the callsback if a callback is provided:

MemoryStore.prototype.clear = function(fn){
  this.sessions = {};
  fn && fn();
};

length 简单地用 store 中的 session 数回调:

length simply calls back with the number of sessions in the store:

MemoryStore.prototype.length = function(fn){
  fn(null, Object.keys(this.sessions).length);
};

希望这对您有所帮助.

这篇关于Node Express Connect - 会话管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！