Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The existing session types mode setting, for whether to expire anonymous users or both anonymous & authenticated user sessions could be expanded to allow configuring which user roles should have their sessions expired. With the attached patch, the anonymous user role & authenticated user role can be selected to replicate the existing behaviour (and an update hook has been included in the patch to transform the setting appropriately), but other roles can be selected as well / instead to restrict the session expiring to certain roles (e.g. only users with certain elevated roles should have their sessions expired, for security, while leaving regular users' or anonymous users' sessions alive).
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | session_expire-select_roles-2370521-5.patch | 9.93 KB | pachabhaiya |
| #4 | session_expire-select_roles-2370521-4.patch | 4.98 KB | pachabhaiya |
| session_expire-select-roles.patch | 4.87 KB | james.williams |
Comments
Comment #1
pachabhaiya commentedThe attached patch does not apply cleanly in the latest 7.x-1.x-dev version. Looks like we have to re-roll the patch.
I'm assigning it to myself and will be re-rolling the patch.
Comment #2
pachabhaiya commentedThere was a conflict in session_expire.module file when re-rolling. Conflicts fixed and patch rerolled.
Now it applies cleanly in the latest 7.x-1.x-dev version.
Comment #3
pachabhaiya commentedWorks perfect for me.
Comment #4
pachabhaiya commentedUpdated some comments and descriptions.
Comment #5
pachabhaiya commentedIt looks like there may be some potential issues with the $max_deletions not getting enforced as expected, in some (edge) cases. It appears that the backlog of sessions get processed from newest to oldest. The two problematic examples I came up with were:
1) If multiple users were to have a timestamp at exactly the same time, we could end up processing more than the limit expected.
OR
2) If more users log in more often than the cron run can process, it can leave some of the oldest sessions still around.
I think that switching to processing from oldest to newest could alleviate the issues mentioned above and/or switching to using the queue API for the deletions.
I have add the updated patch with some @todo comments.