2

To my understanding, when a session is initialized for some user,

the session gets a hash and session_id which identifies it.

ex. session[key]=value 
    session_id = 23f8fzsj2048j20j

Now, when logging out a user, I know you can simply set 

session[:user_id] = nil

But what happens to the actual session hash?

If I'm not wrong, if there is User A, B, and C, they each get assigned a unique session, for example with User A with session_id = 12345abc, User B with session_id = 23456abc, and so on.

Does this not create infinite amount of session hashes then? Are they garbage collected when they do not get used?

innhyu
  • 340
  • 1
  • 13

2 Answers2

2

This depends entirely on the mechanism you're using to store hashes, but the short answer is: No, sessions are not garbage-collected, and they generally don't need to be.

Sessions are (by default) stored using CookieStore. There is no server-side data, all of the cookie data is encrypted and stored in a cookie. The user's browser is responsible for clean-up.

You can use alternative session storage engines, such as ActiveRecord sesssion store which stores session data in the database. Doing this requires you to manually choose when to consider a record "expired", and to implement your own clean-up code, again, they are not automatically "garbage collected": How does Rails know when to delete a record from the `sessions` table?

Community
  • 1
  • 1
user229044
  • 232,980
  • 40
  • 330
  • 338
1

I am not sure what you mean by session_id, but by default sessions are using a cookie that is saved in your users' browser.

If you'd like more reference for the code involved I suggest you read this, https://github.com/rails/rails/blob/3ac3760c69e6e6914c5ddae138856b3c82ac0f20/actionpack/lib/action_dispatch/middleware/session/cookie_store.rb, and then go on and see the Rack implementation for cookies.

As for nullifying a session in the context of logging a user out, most authentication frameworks check for a special cookie with a user id that is set once a user has logged in and when that value is not found in the cookie your are essentially logged out.

The hash itself which gets initialized in the request cycle lives in memory and will be garbage collected at the end of the request-response cycle, in a very naive way, your hash lives in the heap and gets garbage collected.

The data that it is referencing to lives in your browser's cookiejar and has it's own mechanisms for cleaning it.

gmaliar
  • 5,294
  • 1
  • 28
  • 36
  • So I thought when a user sends a request, rails app creates session hashes which are uniquely identified with some IDs. That's what I meant by session_id. Then, whenever a user sends a request with a cookie that has a session_id and user_id, which rails uses to identify a hash and use the user_id as the key to see if the user is logged in. I hope I'm not making wrong assumptions here. Am I? – innhyu Feb 15 '16 at 05:23
  • 1
    What you are saying is correct when using an `ActiveRecord` or `CacheStore` SessionStore, you still have a cookie that references what is your `session_id` but the place where the data itself is saved and retrieved from is different. You can read more information about it here, http://guides.rubyonrails.org/action_controller_overview.html#session. – gmaliar Feb 15 '16 at 09:23