From a mail report (translated from french):
When using session_proxy and redis module altogether, the session cookie was not destroyed upon user logout:
$conf['session_inc'] = 'sites/all/modules/contrib/session_proxy/session.inc';
$conf['session_storage_force_default'] = FALSE;
$conf['session_storage_class'] = 'SessionProxy_Storage_Cache';
$conf['session_storage_options']['cache_backend'] = 'Redis_Cache';
In order to destroy this cookie, the session_proxy\lib\SessionProxy\Storage\Cache.php was modified:
public function destroy($sessionId) {
// Delete session data.
+ SessionProxy_Helper::deleteSessionCookie($this->sessionName);
...
}
This probably isn't the best place to destroy this cookie, nor the best way to do it...
Comments
Comment #1
pounardComment #2
yveslaroche commentedI have the same issue when using the native PHP session handling with Redis. The session cookie is never destroyed.
Comment #3
shubhraprakash commentedWell as I see it, session_proxy module has not implemented any session cookie deletion functions before session_destroy() is called due to it's design as a proxy. The below patch will delete the session cookie during hook_user_logout but may cause issues if someone implements this hook and looks for the session cookie. But otherwise this will do the job.
Comment #4
shubhraprakash commentedPlease see above comment as I posted the same comment twice.
Comment #5
pounardI have to figure out something better regarding the design, but thanks for spotting that. I'll try to see that asap.
Comment #6
pounardOk indeed, problem is I didn't have a cookie delete handler on the session handler, which means that when session_destroy() is called, setcookie() was not.
The actual code is present but commented out, I guess I had problems with it, I'm investigating.
Comment #7
pounardAnd I understood where it fails, it happens only when session_destroy() is called using the native implementation.
Comment #8
pounardOk, and that's because, as documented in https://secure.php.net/manual/en/function.session-destroy.php session_destroy() does not handle the cookie itself, but native implementation has no handler on destroy.
Comment #9
pounardIt took me a while to arrive to same conclusion as you, I have no other choice than react upon the user_logout() hook I guess. There are a few use case where it will prove impossible to delete the session cookie at all, for example: we ourselves do not enable the module but just use the proxy as-is. Still searching for a better way.
Comment #12
pounardI did some fixes and rewrote a few things, but basically it's thanks to you that this fix exists, thanks a lot !
Comment #13
shubhraprakash commentedWell there could be another way of doing it as below and is a better way to deal with it. I avoided it since it was tweaking the original code.
Session handler functions can be registered for native session handling also using session_set_save_handler. Let other functions just return TRUE and let the destroy session handling function call the delete cookie function. This will be very similar to how lib/SessionProxy/Backend/Default.php is doing it.
Comment #14
pounardOh, I didn't know that, if I have some spare time, some day, I'll try to improve this. Thanks anyway!
Comment #15
shubhraprakash commentedPerhaps registering session handler functions may hijack native session handling altogether even if we are trying to override only the session destroy part. I will update if I find a better way to deal to delete session cookies once session is destroyed. The current commit should be good enough for now.
I have one more suggestion. That is to use cache to store $user global data even when we are using native session handling, this will help in bypassing DB altogether when using native session handling with a non-DB cache like memcache. May be we can utilize a hook to clear the session user data cache when a user is updated. This will be great performance wise for authenticated users.
Comment #16
shubhraprakash commentedMay be we can try this patch. I have redone the cookie deletion part and it may be different from what is committed in the previous comment but should get the idea across to modify accordingly.