You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In testing this connector with session storage, I see that it respects the TTL of the cache definition but not sessionTimeout. Consequently, every docker healthcheck and bot is generating a session in redis that lasts as long as the cache TTL and those values are not destroyed by sessionInvalidate().
Is this intended behavior? Whether or not the keys expire according to the cache definition or the sessionTimeout timespan, it does seem that invalidating the session should remove the key from redis.
The text was updated successfully, but these errors were encountered:
A side effect of this problem is that, if you use this extension to store sessions, the sessions will be invalidated according to the TTL and not session activity -- so if your TTL is 2 hours, no session will ever last longer than 2 hours, even if there is activity at the 1 hour and 59 minute mark.
Pretty sure not everybody is being logged out every two hours (our session timeout) ... We are experiencing issues with sessions randomly expiring, with TTL -1 etc.
In testing this connector with session storage, I see that it respects the TTL of the cache definition but not sessionTimeout. Consequently, every docker healthcheck and bot is generating a session in redis that lasts as long as the cache TTL and those values are not destroyed by sessionInvalidate().
Is this intended behavior? Whether or not the keys expire according to the cache definition or the sessionTimeout timespan, it does seem that invalidating the session should remove the key from redis.
The text was updated successfully, but these errors were encountered: