3

Have an ajax call to "updateUser" which does this:

puts session[:user_id]
user = User.find(params[:user_id])
if user
  session[:user_id] = user.id
  session[:user_name] = user.first_name + " " + user.last_name
  puts session[:user_id]
  render text => "Success.
end

The first puts shows the original user_id and the second shows the new user_id, so it would appear to be working properly. However, when I navigate to another page, all the session information is still that of the original user_id. What have I done wrong?

I have a feeling it has something to do with the local session cookie not being updated.

UPDATE

Definitely has something to do with caching. I can go to the page, clear the browser cache (am using Chrome as my browser), then run the ajax call and it works properly once. After that I am locked in to the (new) old user again.

UPDATE 2

Looks like it is something specifically to do with html5 application-cache. If I kill the appcache or run the script from a page that does not include manifest it works just fine. Still can't get it working properly on the cached page.

The same session id is being sent to the server from the cached page as the non-cached page, and the response headers are identical. But each request from the locally cached page causes the server to start with old session information.

Lee Quarella
  • 4,662
  • 5
  • 43
  • 68

4 Answers4

2

http://diveintohtml5.ep.io/offline.html

I can tell that you've got a manifest caching problem, and altering the session itself is not going to clear the manifest. The cache is persistent until such time as the cached item is de-cached or the manifest is invalidated.

Another user ran into this same issue in a different way: they passed their session data in the URI and ended up caching a new application each time the user visited. Their solution may be useful:

How to clear Application cache (HTML5 feature) using JavaScript?

You might also take a look at this, on the various storage caches: http://sharonminsuk.com/blog/2011/03/21/clearing-cache-has-no-effect-on-html5-localstorage-or-sessionstorage/

And finally, a resource on updating a cache file with JS: http://www.html5rocks.com/en/tutorials/appcache/beginner/ This last one I would use after checking if the session ID has changed: update the session ID, then confirm the change, then clear and re-download the cached files.

Good luck. I hope that helps some.

Community
  • 1
  • 1
stslavik
  • 2,920
  • 2
  • 19
  • 31
1

The problem is that the session information is stuffed inside the application cache somewhere, All requests sent to the server are sent using that session info (which was cached on page load). So, we need to update the application cache with window.applicationCache.update() after the successful ajax call. This will cause the next request sent to the server to have the updated session information and all is well.

$.ajax({url: "/contoller/update_logged_user",
  data: {id: user_id},
  success:function(){
    window.applicationCache.update();
  }})
Lee Quarella
  • 4,662
  • 5
  • 43
  • 68
  • InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable window.applicationCache.update(); – karlihnos Apr 25 '16 at 10:19
0

I encountered a very similar problem... had some code to store a user's zip code in session[:zip] when provided with an ajaxSubmit'ed form. Modified the implementation only slightly and suddenly session[:zip] had amnesia. Storing the info in cookies[:zip] worked properly. Path of least resistance.

rthbound
  • 1,323
  • 1
  • 17
  • 24
-1

Would you try setting the session[:user_id] = nil before assigning it with another value user.id and see what happens?

rookieRailer
  • 2,313
  • 2
  • 28
  • 48
  • Did that, didn't work. I also tried creating a new hash, dumping all the session data in to that new hash, running `reset_session`, making changes to the new hash, then dumping all that back to the new session. Didn't work. – Lee Quarella Aug 04 '11 at 21:30
  • What if you do **session.delete :user_id**, and then set session[:user_id] again. But it should have worked when you just set the session[:user_id] to nil. I suspect, you are setting the sessions variable somewhere else as well, which might be causing it to set to some other value. can you search for all the places with **:user_id** ? – rookieRailer Aug 05 '11 at 03:05
  • It is not being set anywhere else, I can assure that. Like I said, reset_session didn't kill it properly, so that's not the issue. – Lee Quarella Aug 05 '11 at 13:35
  • you could try using a **respond_to** block in the action and respond with updateUser.js.erb. You could leave that file empty, or render a
    that says something. With Rails, it is advised to use the convention update_user instead of updateUser, just saying :)
     – rookieRailer Aug 05 '11 at 19:24