Forum OpenACS Q&A: Invalidate all session and login cookies

Request notifications

Dear all,

is there a way to set the server in a state so that it does not accept any of the authentication cookies (e.g. ad_user_login, ad_session_id) it has sent before and force their deletion / re-issuance on the next request?

Collapse
Posted by Gustaf Neumann on
There is no built-in mechanism for this. However, in the sec_handler in the security-procs of acs-tcl you can find the code to force the expiration of the session cookie (ad_session_id) and to force login handler. The session id cookie contains as 4th value the issue time, that you can use for checking.
Collapse
Posted by Brian Fenton on
Hi Michael

I think it's as simple as doing this in the database:

update users set auth_token = 'whatever'

Brian

Collapse
Posted by Michael Aram on

Thank you both for your answers.

Brian, your appealing approach does not work, unfortunately, at least not in our case.

Now, we would add the following snippet to acs-tcl/security-procs.tcl at line 130:

http://cvs.openacs.org/browse/OpenACS/openacs-4/packages/acs-tcl/tcl/security-procs.tcl?u=3&r=1.90#to130

       # essentially "now" now plus kernel parameter session_renew_time
       set hardcoded_constant_timestamp 123456789
       if {$session_last_renew_time < $hardcoded_constant_timestamp} {
           ad_user_logout
           sec_login_handler
           return
       }

Any final comments? :-)

Collapse
Posted by Michael Aram on
...the addition of session_renew_time was an error in reasoning...
Collapse
Posted by Antonio Pisano on
As we are discussing about a similar feature, I investigated about why sec_change_user_auth_token seems to be uneffective. Commit

http://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Aantoniop%3A20180608133913

should fix the issue, but please feel free to review the change, as Lars's comment states the possibility of side effects.

All the best