Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logout on all devices #746

Open
hgani opened this issue Jan 18, 2016 · 6 comments
Open

Logout on all devices #746

hgani opened this issue Jan 18, 2016 · 6 comments

Comments

@hgani
Copy link

hgani commented Jan 18, 2016

Hi,

There are cases where we'd like to invalidate all of the sessions of a specific user.

For example, if a user forgot to log out on a shared computer and someone else obtains access to the account.

Let's say the user notices this and decides to change his/her password.

Ideally, we'd like to be able to delete the sessions on other devices (including the shared computer).

Is this something that can be done in Sorcery?

Thanks

@arnvald
Copy link
Collaborator

arnvald commented Feb 13, 2016

Hi @hgani,

in the master branch we already have this feature. There's a new method in controller called logout_all_sessions- you can try it out. Somehow it disappeared from readme file, I'll add it back there

@arnvald arnvald closed this as completed Feb 13, 2016
@hgani
Copy link
Author

hgani commented Feb 13, 2016

@arnvald thanks for the reply

Just want to clarify that, logout_all_sessions() doesn't do what it means, which is why it has been removed. See #690

@arnvald
Copy link
Collaborator

arnvald commented Feb 13, 2016

Oh, I'm sorry, I forget about it. You're right, that's why it's not in the readme.

Ok, so currently we have the force_forget_me option in combination with logout, but this will only invalidate the remember_me token. It won't invalidate the other active sessions.

I'll leave the issue open then. I doubt I'll have time work on it myself any time soon, but if you or someone else is willing to take it, I might have some idea how it could be done.

@arnvald arnvald reopened this Feb 13, 2016
@fangbyte
Copy link

@arnvald Interested in your take on how this could be done. I'm working on a PR for it now and considering having a configurable column on the sorcery_adapter with a default name of something like invalidate_sessions_before then in https://github.com/Sorcery/sorcery/blob/master/lib/sorcery/controller/submodules/session_timeout.rb adding a method to invalidate the session if the user is logged in and the session is older than invalidate_sessions_before

@arnvald
Copy link
Collaborator

arnvald commented Feb 17, 2018

@fangbyte can you explain a bit more about how your solution would work? How would the invalidate_sessions_before be populated and updated (would it be updated after every user action or would it be a fixed session time)?

The solution I had in mind was:

  1. Add a new column to user model, it could be called session_token
  2. In auto_login method in Sorcery::Controller add session[:token] = user.session_token
  3. Change login_from_session method in a way that it finds user based both on the id and the token.

Then in controller in your application you could add a new action logout_all_sessions which, upon sending request, would log user out and it would change the value of session_token - so all current sessions would be invalid, because they have old value of the token.

This, however, when deployed, will log out all users, so there needs to be some migration mechanism added for seamless production deployment.

@fangbyte
Copy link

fangbyte commented Feb 21, 2018

@arnvald I tagged you in the PR on the newer sorcery project that has a spike of what I am talking about, but I'll link here so if anyone finds this later on it's connected for posterity sake. Sorcery/sorcery#110

invalidate_sessions_before would be populated and updated by the invalidate_active_sessions! method. Which sets the new column invalidate_sessions_before on user to Time.now.in_time_zone when called. In my Spike on this I put all of this in the session_timeout module because I think it is related to the logic of timing out a session, but made it an opt in feature in the config. My rationale for that is that this should be a non breaking change, could be rolled out without logging out existing users, and only if you opt in does it assume you have the invalidate_sessions_before column on user. I would also be willing to refactor this to be it's own invalidate_active_sessions submodule, but it felt like a small bit of functionality to have its own submodule.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants