The README.txt for this module states

This is all backed up by a server side logout if js is disable or bypassed.

However, I have discovered that this is not always the case. If you have a site that does not use any custom roles (you have only authenticated and anonymous), then sessions will never be expired but hook_cron().

hook_cron() queries {user_roles} to determine what roles a user has. "authenticated user" is no a role that is stored in this table. Therefore, the check for if that role should be logged out always returns false (ie: _autologout_logout_role()).

Also, just an FYI, I had to trace through the module code to determine that unless the "Role Timeout: Enable each role to have its own timeout threshold" checkbox is checked (along with at least one individual role checkbox). To me, the description of the checkbox and the README implied that if the box is not selected, then the hook_cron() session destroyer would affect for all roles using the same logout time found in the main "Timeout value in seconds". This is not the case - there is no server-side logout logic that executes be default.

Annotated screenshot attached.

CommentFileSizeAuthor
#3 server_side_session_destroy-2090429-3.patch2.72 KBryan_courtnage
Screenshot of problems47.36 KBryan_courtnage
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ryan_courtnage’s picture

ryan_courtnage CreditAttribution: ryan_courtnage commented
Title: cron session deleter does not work for "authenticated user" role » "server-side" session deleter does not work for "authenticated user" role
ryan_courtnage’s picture

ryan_courtnage CreditAttribution: ryan_courtnage commented

In autologout_cron(), we could just hard-code in the authenticated user role:

// Authenticated user is a system role, and not in {user_roles} 
$account->roles[DRUPAL_AUTHENTICATED_RID] = DRUPAL_AUTHENTICATED_RID;
ryan_courtnage’s picture

ryan_courtnage CreditAttribution: ryan_courtnage commented
FileSize
server_side_session_destroy-2090429-3.patch2.72 KB

I also discovered that the hook_cron does not honor user-specific timeout settings, nor does it honor the per-role settings. It was coded to only use the main "Timeout value in seconds" setting.

The attached patch applies against 6.x-4.x. It fixes the following issues for the server-side session deleting:

  • Only enables the per-role settings if the Role Timeout option is selected.
  • Uses appropriate per-user or per-role settings.
  • Works with the Authenticated User role
    • ryan_courtnage’s picture

    ryan_courtnage CreditAttribution: ryan_courtnage commented
    Status: Active » Needs review
    johnennew’s picture

    johnennew CreditAttribution: johnennew commented

    Hi @ryan_courtnage,

    Thanks for your patch submission - I was never 100% convinced by the hook_cron code.

    For the Drupal 7 version, the approach was slightly different. Are you able to check this alternative approach to see if it would be better to backport this to Drupal 6?

    https://drupal.org/node/1315708#comment-7516809

    ryan_courtnage’s picture

    ryan_courtnage CreditAttribution: ryan_courtnage commented

    Hi @ceng,

    Not sure I understand. That D7 patch will delete old sessions for a user every time they log in. However, I don't see how it would delete my current active session, which is currently over the timeout limit. ex:

    1. Disable javascript in browser (or otherwise break javascript on the site, or use elinks, or use curl/simpletest, etc)
    2. Login as user
    3. Let browser session sit for a period longer than the timeout
    4. Return to browser and use site

    I do not have to login again, and therefore the session deleting code does not run. As far as I can tell, there would be nothing stopping me from using the site (because javascript is disabled).

    If using hook_cron(), the server would be able to delete the user's session after step 3 above, forcing him to re-authenticate.