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.
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.
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();
}})
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.
Would you try setting the session[:user_id] = nil before assigning it with another value user.id and see what happens?
Related
I've built a multi page form wizard for a single model in rails, as a user enters data into the form regardless of the wizard page, the data is saved in session parameters. All works great, until the user finally submits the form, then I want those session parameters to also be cleared out.
I currently am removing the session by its attribute name and then resetting the session. This appears to work, but then if the page is refreshed, the original session will return. I have cleared the cache, and cookies but it seems like this is caused by the browser saving the session somewhere that the delete and rest are not catching.
In my controller after the new object is saved I call this to clear the session
session[:design_attributes] = nil
reset_session
redirect_to :controller => 'designs', :action => 'index'
Am I missing something, that also needs to be removed from the client side session? I would expect that the user, after hitting the above code should never be able to refresh their browser and see the session variables repopulated.
Let's say we have a very simple controller's show action:
def show
session[:shown_counter] ||= 0
session[:shown_counter] += 1
puts "session id: #{session.id}"
puts "shown #{session[:shown_counter]} times"
end
When I hit the url that invokes this action from my browser(chrome), it works as expected and I see the shown_counter increment. But I have a flash that makes some (5-10) requests to the correct URL, invokes my show action, but I can see that the counter is not increased although the session id is always the same.
When I reload the flash, I'll see that the counter increased by 1, but get "stuck" until I refresh the flash again or I make a "regular" request (with the browser).
How does it work? Why the counter doesn't grow with the flash requests?
I believe your Flash app needs to get the session cookie as provided by your Rails app server in a Set-Cookie header, store the data provided, and pass this key-value pair as a Cookie header on its next request.
(Save the _myapp_session=Xyz(etc.) part from each response, in other words, and pass it as Cookie on each subsequent request.)
Otherwise, Rails won't know to which session your request belongs.
After talking to the flash creator, I think I got an answer.
The requests are asynchronous, that means a request won't wait for a response => the cookie won't be updated => the session (that uses the cookie store) won't be updated as well.
I guess this is the scenario, please tell if it makes sense to you and if you agree / disagree.
I am trying to build a website in Rails 4 to track users redirects and site element views.
I decided to use session ids which I believe are quite unique in the short term but I'm having a strange issue.
Example procedure:
user follows a redirect, the system stores this action with a Session ID, let's say xxx
user reaches destination page, which contains a tracker, the system stores this action with ANOTHER Session ID, yyy
user reaches another page which also contains a tracker, the system stores this action with Session ID yyy
After the second action is stored, the session ID stays the same yyy for every request after that, but I need to have the same session ID every time.
In session I also store a SecureRandom.hex generated code, which also changes from the first to the second request (which is not a surprise, since the session ID changes).
I also tried using a cookie, same result.
Please notice that these redirects are external, but all the requests are then made to the same domain (exactly the same, without www and in https).
Any idea?
Thanks in advance.
Update
this is the source code responsible for managing redirects:
before_action :load_redirect, :only => [:http_redirect]
def http_redirect
raise ActionController::RoutingError.new('Redirect has been disabled') unless #redir.enabled
ua = UserAction.create(
:session_id => session.id,
:user_agent => request.user_agent,
:trackable => #redir,
:ip_address => request.remote_ip,
:referer => request.referer
)
redirect_to #redir.destination_url
end
private
def load_redirect
#redir = Redirect.find(params[:id])
end
UPDATE:
Since you are using an iframe (per comment discussion below) for tracking code, the issue is likely that on the external site cookies are not being passed from parent page to the iframe because the iframes origin (domain) is different from the parent page.
OLD ANSWER:
(Still could be helpful for others debugging similar issues)
Source code would help. Without that, here are a few things to try:
Try disabling CSRF protection for the external tracking link action (I'm assuming it POSTs or PUTs data from an external source). CSRF protection could be creating a new or null session for those requests. Put this in the controller that contains the action accepting data from the external source:
protect_from_forgery :except => [:your_action]
The redirect (especially if it's a 301) could be cached in the browser you are using, hence having a different cookie and session than the request your tracking code makes. The stale cookie would be part of the cached redirect.
Try putting cache control headers on your controller action that does the redirect.
response.headers['Cache-Control'] = 'no-cache, no-store, must-revalidate'
response.headers['Pragma'] = 'no-cache'
response.headers['Expires'] = '0'
Your browser may not support setting cookies on a redirect, or possibly third-party cookies. Try in a different modern browser?
There could be a bug in your code. If these solutions don't work, maybe post it?
Background
I'm an experienced web developer (mostly with Python and CherryPy) who has implemented secure session management from scratch before, and is now learning Rails. I'm investigating the behavior of Rails sessions as exposed by the session object that is available in the ActionController instance and view contexts.
Question/Problem
I have read that the default implementation of sessions in Rails 4 uses an encrypted and tamper-proof cookie. Cool, I guess that means I can use it to hold a user ID for user sessions without worrying about session forging (tamper-proof) or anyone being able to find out what their ID is (encrypted). I wanted to test this and see what rails would do if the session cookie was altered.
So, I went and altered the content of the session cookie attribute using a browser add-on, and when I reload the page with the new cookie value, Rails just happily gives me different new values for session_id and _csrf_token.
What happened to session cookie integrity!?
Shouldn't rails detect (via HMAC signature) that the cookie was altered and then tell me about it somehow?
I'm terrified that I'm missing something obscenely obvious, but I've been having no luck searching for an answer on the web, and the source code isn't giving it up easily either (I'm new to ruby). Thanks in advance.
The Experiment
I created a new app and generated a controller with an index action:
$ rails new my_app
$ cd my_app; rails g controller home index
Then I added these two lines to the app/views/layouts/application.html.erb file:
<%= session.keys %><br/>
<%= session.values %>
I started up the dev server and navigated my browser to "localhost:3000/home/index". As expected, the page has the following lines at the bottom:
["session_id", "_csrf_token"]
["8c1558cabe6c86cfb37d6191f2e03bf8", "S8i8/++8t6v8W8RMeyvnNu3Pjvj+KkMo2UEcm1oVVZg="]
Reloading the page gives me the same values, although the app sets a new value of the _my_app_session cookie attribute every time. That seems weird to me, but I'm getting the same session hash values, so I guess it's cool.
Then, I used a cookie editing add-on for Chrome to alter the value of the _my_app_session cookie attribute (replacing the first character of the attribute value). Reloading the page shows completely different values without anything happening. WAT?
I can't claim a really thorough understanding of the code here. But I can tell you this much:
I followed your steps exactly (using Ruby 2.0.0-p247 & Rails 4.0), with one exception -- I also added the 'byebug' gem to my Gemfile and inserted a debugging breakpoint in the HomeController#index action.
From the byebug console, at that breakpoint, I could see the unedited session cookie via:
(byebug) cookies["_my_app_session"]
"cmtWeEc3VG5hZ1BzUzRadW5ETTRSaytIQldiaTMyM0NtTU14c2RrcVVueWRQbncxTnJzVDk3OWU3N21PWWNzb1IrZDUxckdMNmZ0cGl3Mk0wUGUxU1ZWN3BmekFVQTFxNk55OTRwZStJSmtJZVkzVmlVaUI2c2c5cDRDWVVMZ0lJcENmWStESjhzRU81MHFhRTN4VlNWRlJKYTU3aFVLUDR5Y1lSVkplS0J1Wko3R2IxdkVYS3IxTHA2eC9kOW56LS1IbXlmelRlSWxiaG02Q3N2L0tUWHN3PT0=--b37c705a525ab2fb14feb5f2edf86d3ae1ab03c5"
And I could see the actual encrypted values with
(byebug) cookies.encrypted["_my_app_session"]
{"session_id"=>"13a95fb545a1e3a2d4e9b4c22debc260", "_csrf_token"=>"FXb8pZgmoK0ui0qCW8W75t3sN2KLRpkiFBmLbHSfnhc="}
Now, I edit the cookie by changing the first letter to "A" and refresh the page:
(byebug) cookies["_my_app_session"]
"AmtWeEc3VG5hZ1BzUzRadW5ETTRSaytIQldiaTMyM0NtTU14c2RrcVVueWRQbncxTnJzVDk3OWU3N21PWWNzb1IrZDUxckdMNmZ0cGl3Mk0wUGUxU1ZWN3BmekFVQTFxNk55OTRwZStJSmtJZVkzVmlVaUI2c2c5cDRDWVVMZ0lJcENmWStESjhzRU81MHFhRTN4VlNWRlJKYTU3aFVLUDR5Y1lSVkplS0J1Wko3R2IxdkVYS3IxTHA2eC9kOW56LS1IbXlmelRlSWxiaG02Q3N2L0tUWHN3PT0=--b37c705a525ab2fb14feb5f2edf86d3ae1ab03c5"
(byebug) cookies.encrypted["_my_app_session"]
nil
So the session is nil at this point in the request:
(byebug) session
#<ActionDispatch::Request::Session:0x7ff41ace4bc0 not yet loaded>
I can force loading the session with
(byebug) session.send(:load!)
and when I do, I see that the resulting session id is
"f6be13fd646962de676985ec9bb4a8d3"
and sure enough, when I let the request finish, that's what I see in the view:
["session_id", "_csrf_token"] ["f6be13fd646962de676985ec9bb4a8d3", "qJ/aHzovZYpbrelGpRFec/cNlJyWjonXDoOMlDHbWzg="]
I also have a new cookie value now, unrelated to the one I edited.
So from this I think we can conclude is that what's happening is that since the cookie signature could not be verified, the session was nullified and regenerated. I now have a new session, with a different csrf_token.
The relevant code appears at actionpack/lib/action_dispatch/middleware/cookies.rb:460-464, in the EncryptedCookieJar class:
def decrypt_and_verify(encrypted_message)
#encryptor.decrypt_and_verify(encrypted_message)
rescue ActiveSupport::MessageVerifier::InvalidSignature, ActiveSupport::MessageEncryptor::InvalidMessage
nil
end
Rather than decrypting a message with an invalid signature, we just treat it as nil. So the unverifiable cookie that stores the session id and csrf token is not used to load the session, and anything that depends on the values in the cookie will fail.
So why didn't we get an error rather than just a new session? That's because we didn't try anything that depends on the encrypted values. In particular, although we have
protect_from_forgery with: :exception
(as opposed to :null_session) in ApplicationController, Rails does not verify the csrf token on GET or HEAD requests -- it relies on the developer to implement these actions according to spec, so that they're non-destructive. If you tried the same thing on a POST request, you'd get an ActionController::InvalidAuthenticityToken error (as you can easily verify for yourself).
With Rails 3, the default session storage mechanism is cookie_store. I assume that this means that the contents within the session hash are serialized, encoded and stored within a cookie in the browser? Does this mean that nothing (or very little) of the session is stored in the server?
I've had a few issues where I had a cookie overflow error and I'm assuming because I kept on adding to my user instance (which was also linked/fetched from the cookie).
u = session[:user]
u.add_this lots_of_data
so eventually I got a cookie overflow error.
Am I correct about this? Are sessions fully stored within cookies in Rails 3 (by default)?
Yes, if you use the cookie store, the session data is stored in the cookie. If you'd like to store it on the server, you will need to use another session store.
However, if you are storing model objects or "lots of data" in the session, you are most likely doing it wrong in the first place. Your data should go to the database, and the session should only contain as much information as you need to retrieve it.
In you case, this would mean to store the user id int he session, and load the user from the db in a before_filter.
Yes, you are right. The problem might come up if you keep on adding data to session.
But there are some other things that affect it.
Once, I ended up with CookieOverflow error, and the reason was the flash[:notice] messages.
If you use flash[:notice] = "message" and then redirect, the text "message" will be stored in the cookie. If the size of the text u pass is more than 4KBs, you get "CookieOverflow" error