Posted this on stack overflow earlier today here<http://stackoverflow.com/questions/13673969/rails-..., I really either don't know what I'm doing, or I don't understand how sessions are supposed to work! I'm connecting to rails from an Air app and communicating with JSON only. When the client sends a login request, the server makes sure the username & password match, then it does session[:user_id] = user.id, creating the session. But before I send back the login response, request.session_options[:id] is nil, so I seem to have no way of telling the client was his session id is. I did manage to get the CSRF token sent with the login response, which the client sends on subsequent requests. On these subsequent requests, the session id is actually found in request.session_options[:id], so it must be working, just not in the order I expected. So maybe I'm misunderstanding how this is supposed to work. Is the act of the client sending along the CSRF token good enough to validate the session? All my old Rails 2.3 code had me passing the actual session id to the client (and no mention of a CSRF token anywhere), so I'm just wondering if this is just how it's done now in Rails 3.2? If I should still be relying on the session id, how can i send the session id to the client with the login response at the time the session is created? Thanks for taking a look and offering any explanation, this has been a brick wall pretty much the whole day and I'd like to keep working on the actual app writing again 8)
on 2012-12-03 09:21
on 2012-12-03 15:45
Does this help? http://stackoverflow.com/questions/1035933/rails-2-3-session
on 2012-12-03 20:10
It seems like that's in the same vein as my problem, but calling session[:session_id] doesn't seem to be lazy loading the session info. I might try making sure the client also includes the CSRF token along with the login request, but that's an extra server request :/ Anyone know how to force the session to load in rails 3.2?