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

Problem with single_sign_out and devise timeoutable module #66

Open
geoffroh opened this issue Apr 10, 2013 · 2 comments · Fixed by #67
Open

Problem with single_sign_out and devise timeoutable module #66

geoffroh opened this issue Apr 10, 2013 · 2 comments · Fixed by #67

Comments

@geoffroh
Copy link
Contributor

When the devise timeoutable module is included, warden clears sessions after a period of inactivity and redirects to the CAS. Depending on the CAS implementation, this can cause problems because it doesn't know the session was timed out.

I dont think there is an easy solution for this - the bigger problem is that if someone logs in and goes to App A, then uses App B for a while (config[:maximum_session_lifetime]), App A will have timed out. When they next access App A, devise will 'throw :warden' and the user will be redirected to log in again.

Warden has hooks that might be helpful.
(https://github.com/hassox/warden/blob/master/lib/warden/hooks.rb)
def before_failure(options = {}, method = :push, &block)
raise BlockNotGiven unless block_given?
_before_failure.send(method, [block, options])
end

This could be used to initiate a single_sign_out request being sent to the CAS (rubycas-client has some helper methods in https://github.com/rubycas/rubycas-client/blob/master/lib/casclient/client.rb for talking to the CAS), but that means a timeout on any serviced app == a timeout on all serviced apps. Which i think is still preferable to having some serviced apps working as normal and some redirecting to log in, but adding more background requests ruins christmas.

A kludge might be to use that warden hook to redirect to the sign out url so that the CAS can handle killing all of the sessions, but maybe it would be better to just note that option along with the timeoutable issues in the readme. If you think that is a viable option, i'm happy to fork and submit a pull request.

@kylejginavan
Copy link
Contributor

I have the same problem and would love to see it resolved.

@nbudin
Copy link
Owner

nbudin commented Apr 10, 2013

I agree, there's no obvious straightforward solution to this. I'm also not sure what the desired behavior is here: it doesn't seem like timing out the session globally should be the job of a CAS client app.

A README update would definitely be better than nothing, and I'd be very glad to accept a pull request for one.

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

Successfully merging a pull request may close this issue.

3 participants