Node.js&快递会话问题 [英] Node.js & Express session problem
问题描述
我遇到了会话问题,有时会在下一页请求中未定义会话变量I 设置
。为了正确设置变量,我通常需要再次检查流
。
I'm having a problem with sessions, where sometimes the session variable I just set is undefined on the next page request. I typically have to go through the flow again in order to properly set the variables.
我可以确认我没有尝试设置会话变量未定义;它们具有合法价值。
I can confirm that I'm not trying to set the session variables to undefined; they have a legit value.
在我的应用程序中,用户从/ twitter / connect /移动到/ twitter / callback /。前者从twitter中检索了一些oauth数据,后者将用户登录到twitter。
In my app, users move from /twitter/connect/ to /twitter/callback/. The former retreives some oauth data from twitter, the latter logs the user into twitter.
/ twitter / connect /很简单:
/twitter/connect/ is simple:
app.get('/twitter/connect/?', function(req, res){
consumer().getOAuthRequestToken(function(error, oauthToken, oauthTokenSecret, results){
if (error){
// error handling here
} else {
req.session.oauthRequestToken = oauthToken;
req.session.oauthRequestTokenSecret = oauthTokenSecret;
// if I console.log the two session variables above
// they have the proper values.
res.redirect("https://twitter.com/oauth/authorize?oauth_token="+req.session.oauthRequestToken);
}
});
});
之后,Twitter将它们发送回/ twitter / callback /:
After that, twitter sends them back to /twitter/callback/:
app.get('/twitter/callback/?', function(req, res){
console.log(req.session.oauthRequestToken);
console.log(req.session.oauthRequestTokenSecret);
// more often than not, the two variables above are
// undefined. but not always. usually on the first
// pass, never on the second.
});
我不知道发生了什么,我可以确认会话变量设置正确,他们只是没有在页面请求之间保留它们的值,而只是第一次。
I have no idea what's going on, I can confirm that the session variables are being set properly, they just aren't holding their value in between page requests, but only the first time.
这就是我创建服务器的方式:
This is how I'm creating my server:
app.configure('development', function(){
app.use(express.cookieParser());
app.use(express.session({ secret:'yodawgyo' }));
app.use(express.errorHandler({ dumpExceptions: true, showStack: true }));
app.use(express.logger());
app.use(express.static(__dirname + '/public'));
app.set('view engine', 'ejs');
app.set('view options', {
open: '{{',
close: '}}'
});
});
我现在只有一个开发环境。我安装了Node 0.5.0-pre,但是在0.4.1上也看到了这个问题。我正在使用快递2.3.2。
I just have a dev environment for now. I have Node 0.5.0-pre installed, but saw this issue on 0.4.1 as well. I'm using express 2.3.2.
非常感谢任何帮助。
推荐答案
在Connect的会话中,任何处理程序都可以将 req.session.anything
设置为任何值,并且当处理程序调用端()
。如果同时有多个飞行请求,这是危险的;当他们完成时,一个会话值会破坏另一个会话值。这是使用如此简单的会话API (或参见激情源直接),它不支持原子获取和设置会话属性。
In Connect's session, any handler can set req.session.anything
to any value, and Connect will store the value when your handler calls end()
. This is dangerous if there are multiple requests in flight at the same time; when they finish, one session value will clobber the other. This is the consequence of having such a simple session API (or see the session source directly), which has no support to atomically get-and-set session properties.
解决方法是尝试根据需要尽可能少地提供会话中间件。以下是一些提示:
The workaround is to try to give the session middleware as few of the requests as necessary. Here are some tips:
- 将
express.static
处理程序置于会话中间件之上。 - 如果您无法向上移动一些不需要会话的处理程序,您还可以配置会话中间件以忽略任何不使用
req.session
通过说express.session.ignore.push('/ individual / path')
。 - 如果任何处理程序没有写入会话(可能只是从会话中读取),请在调用
req.session = null;
> res.end(); 。然后它将不会被重新保存。
- Put your
express.static
handler above the session middleware. - If you can't move up some handlers that don't need the session, you can also configure the session middleware to ignore any paths that don't use
req.session
by sayingexpress.session.ignore.push('/individual/path')
. - If any handler doesn't write to the session (maybe it only reads from the session), set
req.session = null;
before callingres.end();
. Then it won't be re-saved.
如果只有一个请求一次对会话执行读取 - 修改 - 写入,破坏的可能性会降低。我希望将来Connect会有一个更精确的会话中间件,但当然API会比我们现在的更复杂。
If only one request does a read-modify-write to the session at a time, clobbering will be less likely. I hope that in the future, Connect will have a more precise session middleware, but of course the API will be more complicated than what we have now.
这篇关于Node.js&快递会话问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!