Are class variables session specific?

Rails
1

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.

2

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.

3

On Jan 30, 7:25 am, Ralph S. [email protected] wrote:

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.

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

4

Frederick C. 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.

5

On Sat, Jan 30, 2010 at 5:08 AM, Frederick C.
[email protected] wrote:

I think it is the same on the same, but I’d like confirmation.

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.

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.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: Rick DeNatale - Developer - IBM | LinkedIn

6

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?

7

On Jan 30, 2010, at 3:06 PM, Ralph S. wrote:

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.

8

On Jan 30, 2010, at 3:06 PM, Ralph S. wrote:

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?

Also read here, and in particular, consider DHH’s comment: