I am using Devise gem to handle login/logout in my website. In client i use AngularJS cache is DSCacheFactory.
I have an issue about browser cache or angularJS cache. It is cache still stores old value when session ended.
Example:
login user A
logout user A
login user B
website shows user A.
I expect that after user B login website shows user B
The Angular DSCacheFactory just clears browser cache when they expired.
How to i can clear DSCacheFactory user A after logging in user B (session ends).
I know that post is old, but for future reference if someone need solution to described problem.
You have to check if user is currently signed in with some account and on new sign in attempt just invalidate previous session.
If you override Devise::SessionsController and Create action with that code you should notice expected result. It works correctly with angular devise library
https://github.com/cloudspace/angular_devise
def create
if user_signed_in? && params[:user].present?
sign_out(current_user)
end
super
end
Related
We have a pretty standard React-Rails app with (prerender = true) (following this tutorial and his accompanying repo). We're currently using the Devise gem to implement users. However, right now after a successful login and the user is redirected to the home page (as is the default with Devise - we made no changes there) the user session is not persisted, meaning the user is logged out by the time the homepage is reached, according to the user_signed_in? function provided by devise.
Any suggestions?
I have been using the devise gem for authenticating my rails app for some time now, and I just began to wonder how the current_user works
How does devise saves the current_user?
Browser session?
Application session?
Some other parts of the Application?
I am suspecting that the answer is number one Browser session. Reason being that even when an app gets restarted, and you try to access the app again from a browser that has been used to sign in already, it automatically signs you in.
My confusion though is this: If it is the browser session, it means that when the browser relaunches ( the session was ended ) current_user should be expired, and the user signed out; but it does not work so.
So, how does the current_user operates? thanks for all contributions.
current_user works by storing id of current user in the application session. Most commonly session is stored in cookies. Whether or not the cookies survive browser restart depends on client's browser settings.
If you have clicked remember_me it stores a signed token unique to user in a permanent cookie and stores it in browser. It is saved in database also.
When current_user is called again , rails checks if the permanent cookie exists, if so compares it with the one in database. If they are the same , you are logged in as that user.
If a user starts out in my app unauthenticated and then logs in, I can have my Rails back-end return the user data, and create a User model in my Ember app.
However, what if a user starts out in the app authenticated? How can I use session to fetch the user's details from Rails?
I'm using the ember-simple-auth-devise authenticator.
I was able to use
this.get('session.user_email')
in my application route to find the authenticated user.
The better way to do it is to reopen the session object and add a property that references the authenticated user. See this example from the guides.
I'm using Rail3 with Devise gem. It does a great job when you need to lock user from signing in.
But it works just for new login attempts.
If he is already logged in - it won't sign him out immediately.
Here's is the typical use case:
Given admin user
when detects suspicious activity of certain user he locks it with malicious_user.lock('locking-reason')
% can config/initializers/session_store.rb
AppFoo::Application.config.session_store :cookie_store, :key => '_foo_session'
Given HTTP's statelessness, you can't immediately log out a user because you will need to wait until they make another request to your server. You could get around this via a push service I suppose, but that would be overkill.
My solution would be to add that person to a blacklist and then check if they're on the blacklist whenever they try to access a section intended for logged-on users only. This will render them unable to log on until you decide whether or not their activity is suspicious.
Example:
User is suspected of intolerable activity
Admin wants to check this out, so they temporarily add the user to the blacklist.
User clicks on an area of the page they were currently on when added to the blacklist.
Code checks for loggin status and blacklisted users.
Since the user is blacklisted, they are informed that they need to sign in to access the content
Once the user tries to sign in again you can inform them that their account has been temporarily disabled (or you can do this in the previous step).
perhaps the easiest way would be to redirect the user to the logout action when you lock them so:
malicious_user.lock('locking-reason')
redirect_to '/logout' and return
I'm not familiar with Devise so this may not be the best solution or even possible but it's how I would approach the problem
Use a before_filter in the ApplicationController that will do the following
before_filter :kick_out_blocked_user
protected
def kick_out_blocked_user
unless current_user.try(:active?)
redirect_to destroy_user_session_path
end
end
just wanted to know:
In my rails 3 app when a user logs in, i store their id in a session variable like this
session[:id] = #user.id
i noticed that when i login and then close the browser the session is destroyed. Is this wise to do or better to create a logout feature to destroy the sessions. What can go wrong if i leave it as is.
Thanks for help
I noticed that when I login and then
close the browser the session is
destroyed. Is this wise to do.
If this is happening then it's good if session get expired/destroyed when user closes browser. This is what mostly done in websites.But can be hard when you are trying to providing remember me or always sign in like functionality. In this case you might not have to destroy session when browser is closed.
or create a logout feature to destroy
the sessions.
You can create a logout feature to destroy session but call this when user hits logout link.