Closed BizShuk closed 9 years ago
Yes, this is because the session_secret
will be regenerated each time. So to work with lua_code_cache off
you need at least this configured (in nginx or with your lua code):
Nginx:
#change the secret
set $session_secret 623q4hR325t36VsCD3g567922IC0073T;
Or in Lua:
local session = require "resty.session".start{ secret = "623q4hR325t36VsCD3g567922IC0073T" }
I look if this can be fixed, but I'm not sure if there is a solution to this. Maybe the solution here is just to document that secret needs to be set if you run with lua_code_cache off
. It is always good to define your secret, then your sessions will work even with nginx restarts.
It is now documented here: https://github.com/bungle/lua-resty-session#notes-about-turning-lua-code-cache-off
I think that this is all that we could really do with this (unless we cache the secret in somewhere, but that has its own problems associated). So my conclusion, now that this has been documented, this is considered fixed. If any of you have a better solution to this, we can reopen. I can only think about storing secret in shared_dict (but that needs shared dict configurations), db (like redis etc., but that adds dependency). So the only place looks to be to store it in files but that would of course break when used with many servers front-ends.
Another fix is that you run (works fine with single server):
require "resty.session"
in your init_by_lua
.
So there are many ways to overcome this issue already that work better than adding some weird logic in lua-resty-session
.
I'm also experiencing this when there are multiple workers. In some workers the cookie was loaded, and in other it didn't. The statement "require" does indeed happen in the handling code itself, so I guess it is better to require this stuff in an init phase? Or at least set a secret in the global configuration?
"lua_code_cache off" effect session. I think it is may simular like session off. So if you check it as same as i say , it could mention on Readme.md. :)