I'm trying to wrap my head around what information is session specific and what isn't.
If I do User::x = 1 will User::x == 1 for all sessions on the same machine?
I think it is the same on the same, but I'd like confirmation.
I'm trying to wrap my head around what information is session specific and what isn't.
If I do User::x = 1 will User::x == 1 for all sessions on the same machine?
I think it is the same on the same, but I'd like confirmation.
I believe class variables are shared between sessions and are unsafe storage for session-specific information. If you're looking for session isolated variables which can be accessed anywhere in your app, try using Thread.current.
It will be the same for all requests handled by that particular instances. If you have a pool of passenger/mongrel/thin/unicorn/etc instances then each one would have a different value.
Fred
Frederick Cheung wrote:
If you have a pool of passenger/mongrel/thin/unicorn/etc instances then each one would have a different value.
Sigh ... more things for me to learn.
Thanks for point that stuff out.
And different requests for the same session might well run on different instances, so see different values.
Same problem with the suggestion to use thread local variables made by a responder to this thread.
I'm pretty sure that the only way to deal with values which have to be seen between requests is to either put them in some persistent storage on the server (e.g. the DB, SQL or noSQL), or in the session and let the browser give it back to you.
I'm pretty sure that the only way to deal with values which have to be seen between requests is to either put them in some persistent storage on the server (e.g. the DB, SQL or noSQL), or in the session and let the browser give it back to you.
So ... are "params" visible to 3rd parties if session management is done via a cookie-based approach? If using ActionController::Base.session_store = :active_record_store a better way to do things? If so ... why isn't this the default?
This is kind of old news, but read here to see why your cookie-based sessions are tamper resistant: http://www.rorsecurity.info/2007/11/20/rails-20-cookies/
With other session stores, you had to manually clean up periodically -- sweep up the expired cookies. It's waaaaaaaay easier this way.
Also read here, and in particular, consider DHH's comment: Latest Relevance Open Source: encrypted cookie store