Now my rails session ends when i close browser. Its' not than i want. I need to create applciations where sessions never ends.
How can i do it?
Thanks.
Make a cookie that will login your user every time (s)he visits your site. If that's what you really want.
Know that when your user closes the browser, the session will not "really" end. Since HTTP is stateless, your server will not know when the browser is closed. Hence, this will not end the session.
So, if you want the session to never end, do as what I said in the first paragraph. But think about the consequences when your users are at a public terminal, like an airport. If somebody logs in your site and closes the browser, and somebody else visits your very site, this person will have previous persons' credentials. Do you really want that?
In Rails, there are many gems to handle this. It sounds like you need to read up on sessions first. This is not a Rails-specific or Rails-innovated concept. Basically, you need to create users with passwords that you store in a database in an encrypted manner. As #darioo said, you don't want every user to have the same session, do you?
Once you've read up on the philosophy (google it for a few minutes), then you should look at the following gems:
Devise: https://github.com/plataformatec/devise
Warden (used by devise, et. al.): https://github.com/hassox/warden
You can then add devise to your Gemfile and progress from there.
Related
I am using this answer here to log unique page views in my app: https://stackoverflow.com/a/15174466/1235816
I am using a cookie to check for unique visits. As far as I am aware, because the site will be hosted in the UK, I should have a message which asks the user to accept cookies or if they don't... it asks them to leave the site.
I want it to work like this... If a user wishes to accept cookies, then the 'app-name-visited' cookie should then be downloaded, otherwise if they just exit the site without clicking accept, no cookies are downloaded to the clients machine...
Is this:
1/. a correct way of thinking?
2/. possible?
The cookie law has since been modified, so this is not quite necessary any more, you only need to let the user know that they you will be using cookies.
The organisation that enforces this is the ico, which doesn't ask for permission for cookies on their site:
http://www.ico.org.uk/
Suggest you follow this pragmatic approach.
If you are wanting to comply as per your question I did some work on this a while back for rails projects which should be a decent starting point:
https://github.com/yule/threepwood
I have an rails app which relies on authenticating username/password entered to an external webservice. Rails app will not have a user model. When a user enters login/password and it makes a post request to check that login/password. External application will return back a cookie or token which can be used for subsequent requests made from rails app.
There is no User model in the rails app since all the users are stored in an external application.
Is there a gem which let me strictly do session management? I'm planning on storing that token in a session.
why not just create a sessions controller that saves the token into a session? I don't see a need for a gem.
something like
sessions[:token] = token
If you are dealing with a tokens that expire like facebook you can take a look at this
http://developers.facebook.com/blog/post/2011/05/13/how-to--handle-expired-access-tokens/
hope it helps
I might look at the way Michael Hartl does user sessions in his Rails tutorial. What you want is something slightly different, but you might be able to reuse some of what he did there. http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec-current_user
(It's also just a good tutorial to go through, regardless of your level of Rails experience.)
I'm now on level 7 of Hartl's rails tutorial book and I'm starting to think about my application in deployment. It's an app that allows about 12 social workers to communicate collaboratively and privately. Thus, I need to password protect it.
However, it also needs to be easy to use, very easy to use. A few of these people haven't used a computer before, and having logging on and sign-up processes would put them off completely.
Thus I want to create a landing page, where they have to type a password in (the same password for everybody), then it redirects to the 'discussion pages.' My first idea was to use some obfuscated javascript such that upon typing in the password, it redirects them to the discussion pages, but this doesn't sound very secure.
Can anyone recommend me a better way to do this in rails? Ideally they would only have to type it in once, and then it would authenticate them for all the pages automatically (by setting a cookie?) and anyone trying to access a page directly would be redirected to the authentication page.
Cheers in advance
A very simple authentication option is available to you in this situation. I would suggest you watch the Ruby on Railscast episode 270. I think it just maybe what you are looking for.
If you want really simple, you can use authenticate_or_request_with_http_basic
It's not a replacement for a real authentication system, e.g. Devise or AuthLogic however.
I started to use the lockup gem for this purpose:
https://github.com/gblakeman/lockup
It is super easy to setup and almost every user accessing the site should be able to use it.
Specifically, I have written a Rails app in which I'm using the default (in Rails 2.3.5) CookieStore session store and I've spotted an odd problem in development.
Myself and a few others had been using the site for a few weeks and we each had a login based on a username and password (each user registered themselves and I stored the (salted and hashed) data in the database). I was storing the user ID in the Rails session object (and, therefore, in the cookie that is passed back and forth between browser and server).
One important point here: since this is an intranet site, I set the cookies to stay alive for up to 2 weeks to avoid users having to log in all the time.
Today I reset the database, wiping all user records (and all other data, intentionally). A few users started registering themselves again and then one user found that the first time they went to the site since the wipe they were automatically logged-in as a different user!
I think I can see why this happened: the user ID passed from that user's browser to the server now matched a different user-record in my database. My initial thought was "oh dear, I wasn't expecting that!" but the more I thought about it the more I realised this was probably expected behaviour.
I realise I can change my Rails app to user ActiveRecordStore but before I did that I wanted to make sure I understand what's going on here. Specifically, does the combination of using CookieStore sessions and having the sessions stay alive for some time really create such a gaping security hole? Or am I missing something? Should the session_id be providing a little more security here?
The big security hole in this setup isn't the cookie length, it's setting the user_id in a cookie. This means that anyone who logs into your site can log in as anyone else just by changing that cookie! A hacker would just sequentially walk through user_id's, logging in and seeing if there's anything they want to steal or abuse.
If you want to roll your own authentication, try this instead: add a "token" string field to your user table. When somebody logs in, set this token to a random set of numbers and letters, and pass that as the cookie back to the user. The token should be at least 32 characaters, alphanumeric, upper and lower case.
Now when a user goes to a page, their account is looked up by that hash instead of their user_id. The value is that the hash is much harder to guess, and will never be repeated. Your user_id's were actually repeated when you reset the database, causing people to be logged in as each other.
UPDATE
#shingara is right that the cookie store does handle the security part already, my mistake. The user_id mixup is therefore a one-time occurrence because you reset the database. This is not a problem you'll face in a production environment, unless you reset the database again. If resetting is ever a possibility, then still do the token creation as I recommended. Otherwise, you're fine.
The simplest solution to the problem you had here would be to have changed the cookie name when you reset the database. The cookie name should be in config/initializers/session_store.rb
ActionController::Base.session = {
:key => '_your_app_session_v2',
You could also change the secret, but that may generate errors for your users if they request the site with an old cookie.
You case arrived only if you have 2 differents user with the same user_id. So it's not possible if you define the user_id like unique.
Another case, you can add in session, an hash with an unique key by user. when you check the session you get the user_id and check if the user_token is same . If not, the user is not authorized.
Thankyou for all the responses. They all answered my question in a way: yes, my setup (and my not setting a new session key after wiping the users) creates a security hole.
Lots of Rails tutorials advocate this setup without mentioning the fact that all you need is to monkey with your cookie to be fully authenticated as another user.
So, to summarise, I asked the question because I couldn't find anything discussing the danger of CookieStore session + long cookie lifetimes, and I found that surprising so thought I might be missing something obvious.
I had a similar issue and resolved it using a code snippet similar to
this comment by mdesantis on managing Rails secret token
My Rails-app has a sign in box with a "remember me" checkbox. Users who check that box should remain logged in even after closing their browser. I'm keeping track of whether users are logged in by storing their id in the user's session.
But sessions are implemented in Rails as session cookies, which are not persistent. I can make them persistent:
class ApplicationController < ActionController::Base
before_filter :update_session_expiration_date
private
def update_session_expiration_date
options = ActionController::Base.session_options
unless options[:session_expires]
options[:session_expires] = 1.year.from_now
end
end
end
But that seems like a hack, which is surprising for such common functionality. Is there any better way?
Edit
Gareth's answer is pretty good, but I would still like an answer from someone familiar with Rails 2 (because of it's unique CookieSessionStore).
You should almost certainly not be extending the session cookie to be long lived.
Although not dealing specifically with rails this article goes to some length to explain 'remember me' best practices.
In summary though you should:
Add an extra column to the user table to accept a large random value
Set a long lived cookie on the client which combines the user id and the random value
When a new session starts, check for the existence of the id/value cookie and authenticate the new user if they match.
The author also recommends invalidating the random value and resetting the cookie at every login. Personally I don't like that as you then can't stay logged into a site on two computers. I would tend to make sure my password changing function also reset the random value thus locking out sessions on other machines.
As a final note, the advice he gives on making certain functions (password change/email change etc) unavailable to auto authenticated sessions is well worth following but rarely seen in the real world.
I have spent a while thinking about this and came to some conclusions. Rails session cookies are tamper-proof by default, so you really don't have to worry about a cookie being modified on the client end.
Here is what I've done:
Session cookie is set to be long-lived (6 months or so)
Inside the session store
An 'expires on' date that is set to login + 24 hours
user id
Authenticated = true so I can allow for anonymous user sesssions (not dangerous because of the cookie tamper protection)
I add a before_filter in the Application Controller that checks the 'expires on' part of the session.
When the user checks the "Remember Me" box, I just set the session[:expireson] date to be login + 2 weeks. No one can steal the cookie and stay logged in forever or masquerade as another user because the rails session cookie is tamper-proof.
I would suggest that you either take a look at the RESTful_Authentication plug in, which has an implementation of this, or just switch your implementation to use the RESTful Authentication_plugin. There is a good explanation about how to use this plug in at Railscasts:
railscasts #67 restful_authentication
Here is a link to the plugin itself
restful_authentication
The restful_authentication plugin has a good implementation of this:
http://agilewebdevelopment.com/plugins/restful_authentication
Note that you don't want to persist their session, just their identity. You'll create a fresh session for them when they return to your site. Generally you just assign a GUID to the user, write that to their cookie, then use it to look them up when they come back. Don't use their login name or user ID for the token as it could easily be guessed and allow crafty visitors to hijack other users' accounts.
This worked like a charm for me:
http://squarewheel.wordpress.com/2007/11/03/session-cookie-expiration-time-in-rails/
Now my CookieStore sessions expire after two weeks, whereby the user must submit their login credentials again in order to be persistently logged-in for another two weeks.
Bascially, it's as simple as:
including one file in vendor/plugins directory
set session expiry value in application controller using just one line
I would go for Devise for a brilliant authentication solution for rails.