Is it possible to show "Already Logged In" message if that user is logged on one of the machine.
This thing is possible using database.
But i had implemented sessions for login and logout,i think it isn't possible with sessions to show "Already Logged In".
Please suggest best way for this.
If they go to another computer? If you are using session[:something] - it is stored in the browser. For anything to be stored across a different browser, you have to use a database for state.
I think it is possible, but that being said, I don't like it. I take it you are concerned because you can't easily identify a user from the session data?
Make sure the User model is updated every time a user accesses the application by using a before_filter in the application controller.
During the login process, you can query "logged in" users by specifying a time limit that is the same as the session clean up time limit.
You can do something like this :
User.where("email = ? and updated_at >= ?",login_email,20.minutes.ago)
If you want to avoid concurrent logins for the same username. The best implementation can be achieved by adding a column to the users table that stores the ip address of the logged in user.
Otherwise you can change the session store mechanism to use either of:
ActiveRecordStore
FileStore
DRbStore
MemoryStore
in addition to the default CookieStore.
Related
I have an application built using Ruby on Rails. I use Devise for authentication and CanCanCan for authorization.
My users have two roles, admin and common user. Admin can do everything on the system and common can do limited tasks.
Now a need that everytime a common user tries to do something that needs admin privileges the application asks for an admin password to authorize only that operation.
I have made a research about the topic, but nothing relevant have been found.
I want to know if anyone have done something like this before and how, or if you have suggestions of other approaches to solve this. Thanks in advance.
The easiest way I see is to create a view and a field in database for those purposes.
You can add a field authorized_as_admin_at with a datetime type to the users table.
When you realize that the user needs admin access you:
Check if authorized_as_admin_at was not more than N hours/minutes ago (this method should be in before_filter in ApplicationController or smth identical in your case if you have more complex structure).
If it was, allow them to do what they want, otherwise:
Save the request path in the cookie
Redirect them to the page where they can input admin credentials
If credentials are right, you set autorized_as_admin_at to a current time
Redirect them to the path stored in the cookie.
You can try to store smth like this in session, but that does not look very secure.
I have ror app where i can poll. How to remember user without registration? That he could not vote many times for the same answer.
What should I use? I need to create a new model for users? Maybe use some gems?
Every visitor to your Rails website will be given a session, you can just store some state in there like: session[:seen] = true and in subsequent requests you can check for the existence of that session variable.
See here for more and especially note that a user can always thwart this effort by clearing their cookies (which is why it would be better to use registration).
I'm using devise/cancan for my app and everything is pretty sound -- provided a user creates an account and signs in.
What I'd like to do is allow a user to get started without creating an account. And then sign up if they want to actually save their work.
Has anybody come across this before? Should I be figuring out how to create dummy accounts with devise? Or allowing unauthorized users access to creating models in my app via CanCan?
I could go into detail about how I've been thinking about approaching this, but it feels like a pretty obvious use case that somebody has come up with a nice solution for.
Thanks in advance,
Mike
If you go with creating dummy accounts, you would have to track the user somehow via a cookie and cache the values in that cookie in your db. Cancan does allow for guest accounts via the ability model. For example:
user ||= User.new # Guest user, for users who are not registered or don't have an account yet
Which is enough you to you started with applying permissions for non registered users. Note though, tracking by cookie alone is not very reliable and can lead to some type of security hazard (i.e. by means of cookie hijacking). User, one day, can also decide to clear out his cookies.
If need be, I would suggest letting the user do minimal interaction with a guest account and motivating the user to sign up / register with Devise as much as possible.
Hope that helps!
I actually am considering the same problem, I have a scheduling app that makes a calendar. To get over the problem I'm thinking that you use
user ||= User.new
Like was suggested above and using cookies to get the data to the database once the user creates an account.
This would mean that you would not have to worry about clearing out cookies because they would create an account if they want to save data.
I want to build and maintain a table of users. All users that access the ASP.NET MVC site are authenticated via Windows Authentication so they're bound to have a unique username. I'm grabbing the user name from:
System.Web.HttpContext.Current.User.Identity.Name
I feel like I could go two ways with this.
Anytime the user table or any tables that references the user table are accessed, I could add the user if it doesn't exist. I'm worried this might be very error prone if user's existance isn't checked.
Anytime the user visits any page on the site, check if that user exists in the db and if they don't exist, add the user. This may have a lot of overhead as it'll be checked every page change.
I'd like to hear which of these is the better solution and also how to implement them.
I think a better way would be something similar to the option two.
Anytime a user visits a page, check a session variable to see if that user was checked against the DB. If the session variable is not there, check if that user exists in the DB, add the user to your table if necessary, then set the session variable.
That way you don't have to hit the DB on every request.
I'm looking at implementing some form of anonymous user system in Rails. I need to let people do things (creating records, looking at what they've created, etc), without actually creating an account. Once they create an account, everything persists without risk of losing it by clearing cookies or something.
Right now, I'm thinking it's pretty straightforward. Have an is_anonymous field in the User model, and use something like this to access the currently logged in user:
def find_user
session[:user_id] ||= create_new_anonymous_user.id
end
Assuming the session persists for some reasonable period of time, and the session cookie doesn't expire, that should keep everything running smoothly.
However, there is this piece of me that is convinced that I'm missing something security-related. Has anyone done something like this before? Am I missing something super-obvious?
Thanks!
The only real security issue is going to be if these anonymous users can perform critical operations.
Your system means that anyone with the specific cookie will gain access to the site. Not necessarily a big deal, but it really depends on the type of information your users are providing.
I have done something similar in the past (in my case I was tracking progress through a site and when the user logged in or registered, I attached the "guest" data to their account. When you do the switch, make sure you delete the anonymous record to prevent further access and it should be fine.
I just found a pretty cool example of "trial users" using Authlogic: http://github.com/gisikw/authlogic_trial
Assuming the session persists for some
reasonable period of time, and the
session cookie doesn't expire, that
should keep everything running
smoothly.
Perhaps you should set a separate long lived cookie for the new user, so they can have multiple sessions (at least from that browser).
Are you sure that you want to let people create objects that are tied to accounts that may not exist? Unfortunately I don't know much about what your application is actually doing but I would think that going down this path might leave you with a bunch of orphaned objects not really "owned" by any real users.
If you really do want to do this I think what you have is decent. You could be creating a real user, flagged as "guest" (or whatever) and once the user wants to really register they are prompted for other information and unflagged. You should add access control for guest vs non-guest, etc.