We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 21255
    • 215 Posts
    Just coming from a thread in the German community where a user complained his session stays active for hours (depending on the settings in his php.ini). Wouldn’t it be a good thing to reject sessions older than one hour?
      • 22303 MODX Staff
      • 10,725 Posts
      If you check the remember me box in the default weblogin or manager login, it sets the session cookie expiration date for the domain to time() + the number of seconds indicated by number in the appropriate $_SESSION variable: $_SESSION[’modx.mgr.session.cookie.lifetime’] or $_SESSION[’modx.web.session.cookie.lifetime’] respectively. Currently, both of these can be controlled via $modx->config[’session.cookie.lifetime’], though there is no interface for managing this currently. You’ll need to edit the row in {table_prefix}system_settings with the name session.cookie.lifetime, indicating the number of seconds the session cookie should remain valid after each successful request that accesses the session. By default, this is set to 604800 seconds, which is 7 days.

      If not checked, the session cookie expires when the browser is closed.

      Both of these do not take into account session garbage collection that is determined by the php configuration, which will wipe out sessions regardless of the session cookie maintained in the client browser. You could attempt to configure these in the startCMSSession() function contained in config.inc.php if allowed in your environment, but it is still limited by standard PHP session behavior.
        • 21255
        • 215 Posts
        Hmm, even if the cookie expired, the session is still available on the server and could be hijacked. I know about session.gc_maxlifetime in php.ini but since you can’t set this reliably I’d prefer to make use of [tt]$_SESSION[’modx.session.created.time’][/tt] to check the age of that session. This conflicts somehow with the "remember me" functionality and I have no idea, how that could be solved.
          • 4018
          • 1,131 Posts
          Granted, the way MODx handles sessions is fairly sound. However, it’s still probably worth investigating a little further to insure that sessions are handled in a more standardized fashion based on industry proven methods. So...let’s read the following article on CNet:

          http://reviews.cnet.com/4520-3513_7-6627057-1.html

          There’s also a link to a PDF file from Acros security at the end (http://www.acros.si/papers/session_fixation.pdf). Good info in that too.

          I also found a class on PHPClasses.org that might be good for reference purposes: http://www.phpclasses.org/browse/package/2794.html

          Hope this info helps! I’ll be investigating it further to see if we can perhaps dedicate a class to the authentication and creation of sessions in MODx. Figure that would be a good thing. smiley

          Jeff
            Jeff Whitfield

            "I like my coffee hot and strong, like I like my women, hot and strong... with a spoon in them."
            • 22303 MODX Staff
            • 10,725 Posts
            This is already done Jeff, all based on that paper. Please see the modUser class in the 0.9.7 branch.