bungle / lua-resty-session

Session library for OpenResty – flexible and secure
BSD 2-Clause "Simplified" License
320 stars 111 forks source link

lua_code_cache off; #15

Closed BizShuk closed 9 years ago

BizShuk commented 9 years ago

"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. :)

bungle commented 9 years ago

Yes, this is because the session_secretwill 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" }
bungle commented 9 years ago

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.

bungle commented 9 years ago

It is now documented here: https://github.com/bungle/lua-resty-session#notes-about-turning-lua-code-cache-off

bungle commented 9 years ago

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.

nicolasfranck commented 4 years ago

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?