Destroying Sessions

Hi Glen,

Great bug report and research, thanks! :)

We've been battling with PHP sessions for a while.  The issues are the various web hosts servers delete them too soon, too late, or not at all.  Sometimes multiple websites on the same server use the same /tmp/ folder and erase each others session files when they shouldn't, and in this latest case that you found, sometimes we have developers using other 3rd party apps that use sessions, so we've had to stop destroying the entire session or we risk erasing data used by another web app on the same server.

In v2.51 we addressed some of the previous issues by bypass session altogether for login data and just using a cookie.

For the issues you've mentioned, those are bugs with the current version so I've applied the following patches.  Can you try them and let me know if they work for you?

In /lib/login_functions.php in the function user_logoff() I've added the code in red (just search for user_logoff):

function user_logoff($redirectUrl = '') {
  loginCookie_remove();                   // erase login cookie
  $GLOBALS['CURRENT_USER'] = false;       // clear user global

  // 2.52 - clear saved CMS session data
  if (isset($_SESSION['lastRequest'])) { unset($_SESSION['lastRequest']); }

  // redirect/refresh page



This will ensure that when users logoff their previous view states (stored in $_SESSION['lastRequest']) will be cleared including sort field, page number, keyword searches, etc.  Had this been in place you would have been able to logoff and login again to fix the issue.

Next, in /lib/menus/default/list_functions.php I've added the follow code (in red) - search for this text: _REQUEST from _SESSION 

  // Load last _REQUEST from _SESSION (current _REQUEST values override old ones)
  if (@$_SESSION['lastRequest'][$tableName] && !$isRelatedRecords && !@$_REQUEST['_ignoreSavedSearch']) {
    $sortByField        = @$_SESSION['lastRequest'][$tableName]['sortBy'];
    $invalidSortByField = $sortByField && !@$schema[$sortByField];
    if ($invalidSortByField) { unset($_SESSION['lastRequest'][$tableName]['sortBy']); } // v2.52 remove invalid sort by fields
    $_REQUEST += $_SESSION['lastRequest'][$tableName];
  };

Which will ignore previously saved invalid fieldnames so you won't be that error if the sequence of events re-occurs.

Can you give both of those a try and let me know if it resolves the issue for you? 

Thanks!

Hi Dave.

Dealing with the second item first:

  // Load last _REQUEST from _SESSION (current _REQUEST values override old ones)

Your code update does solve the problem.

As for the first issue:

function user_logoff($redirectUrl = '') {...

I am aware of this function and it was here that I discovered you had removed the session destruction.

I have also read in other recent threads you are having problems with zero byte sessions.

// 2.52 - clear saved CMS session data
  if (isset($_SESSION['lastRequest'])) { unset($_SESSION['lastRequest']); }

Your update removes the "'lastRequest'" session data but if no other session data exists it leaves behind a zero byte session which users seem to be having issues with.

Here are couple of suggestions that would help to get rid of the dreaded zero byte sessions.

In addition to your update continue to destroy the session if it is empty :

function user_logoff($redirectUrl = '') {
  loginCookie_remove();                   // erase login cookie
  $GLOBALS['CURRENT_USER'] = false;       // clear user global

  // 2.52 - clear saved CMS session data
  if (isset($_SESSION['lastRequest'])) { 
    unset($_SESSION['lastRequest']); 
    // If the session is empty after removing the CMSB 'lastRequest', then destroy it since there is no apparent value.
    if(!count($_SESSION)) session_destroy();
  }

  // redirect/refresh page

The other time a zero based session is created is when the login page is loaded.

So if you are not being redirected when you log off, the login screen appears but a zero byte session would also have been created earlier in the procedure. 

You could destroy the session at this point as well in lib/admin_functions.php

// if no logged in user
  if (!$CURRENT_USER) {

    // perform login screen maintenance actions - useful place to run common operations
    if (!$action) {
      createMissingSchemaTablesAndFields(); // create/update missing schemas, etc

      // show helpful messages
      if (!mysql_count('accounts')) { alert(t("There are no user accounts in the database.")); }
    }

    // show login screen if user not logged in
    if(!count($_SESSION)) session_destroy();  // destroy the newly created empty session
    showInterface('login.php', false);
    exit;
  }

If a user/visitor arrives at the login page for what ever reason a session will not exist until authenticated.

I've tested this in ver. 2.51 and my suggestions seem to work without any issues. 

We've been battling with PHP sessions for a while. The issues are the various web hosts servers delete them too soon, too late, or not at all. Sometimes multiple websites on the same server use the same /tmp/ folder and erase each others session files when they shouldn't, and in this latest case that you found, sometimes we have developers using other 3rd party apps that use sessions, so we've had to stop destroying the entire session or we risk erasing data used by another web app on the same server.

The difficulties with other "apps", "plugins" and "servers" makes me want to ask the question:  Are you trying to solve a problem that is "not" a CMSB problem?

The other thing I've noticed is a departure from the separation of CMSB and Plugins. 

As a user of CMSB it's my expectation that CMSB will be rock solid and stable without any "active" plugins. The current session issue makes we wonder if you are not adhering to any rules with respect to seperation of CMSB from other influences.  

Changes to your stable back end to solve a 3rd party issue I think is fundamentally wrong which, as is in the case of the current issue, has broken the back end.

For example, I've come across code in CMSB to solve/fix issues with your "Website Membership" plugin. Since the code relates to a specific plugin issue it should be in the plugin and accessed via a "Hook".

You as the developer of CMSB can add "hooks" where ever you like to address specific plugin issues for plugins you create.  Thus new versions of CMSB should only consist of new features and fixes in addition to new hooks to your already stable release.  Hooks theoretically will never break the back end.

Does IA have a design philosophy in this regard such as is the case in the philosophy of "separation of church and state" where the state is CMSB and the church is things like servers, apps and plugins?

This philosophy will ensure that CMSB can continue to be improved upon in its all ready feature rich state and remain stable. Specific issues as they relate to plugins can be isolated and worked on with breaking CMSB for those aren't using any particular plugin.

I think CMSB is fabulaous and the ability to perform customization via plugins is out standing. 

I am interested in knowing if IA has an official position on the relationship of CMSB to Plugins that I have talked about here. 

Thanks for sharing Dave.

Actually, your response was so thorough I thought maybe you were feeling a need to be defensive.  That was not my intention and hope you did not interpret my questions or comments in that way.

I turned on the "useThisBetaFeature" and it "did" removed the zero byte sessions.

To you and your team, thanks for the great product.

Hi Glen,

Actually, I was just happy to "geek-out" with you for you a bit and tell you about the internals and design philosophy.

We don't often get to talk about that so I appreciate your interest and feedback.  

Cheers! :)