We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
MODX Community Forums Archive

Closing Sessions on browser close

    • 6902
    • 126 Posts
    debussy Reply #1, 14 years ago
    I keep finding exactly the wrong information that I need on sessions. I am trying to make it so that the MODX session is closed when the window is closed (or at least when the browser is quit). Is there a way to do this? We have a multi-stage form and are using sessions to carry data across several pages. The problem right now is that when an end user decides to quit in the middle of the form, all of their (sensitive) data is still there when you relaunch the browser.

    Can this be done?! Is there at least a way I can set the session to time out after say 10 or 20 minutes (and destroy the data)?

    MODX 2.2.4 ... I hate asking for this type of question that I could probably figure out on my own given a little time, but I have been developing for 18 hours straight now (and brain-fried) and I'm under the gun to get this thing out the door. Any little help would be appreciated!
      • 28042 ☆ A M B ☆
      • 24,524 Posts
      sottwell Reply #2, 14 years ago
      There's a few ways you can do this.

      1. Session garbage collection - since Revo saves the session in the database, you can make a plugin to remove the session if the user comes in again after x amount of time. See "endSession" here http://api.modx.com/revolution/2.1/_model_modx_moduser.class.html

      2. Javascript - do like the manager does, and flag a form as "dirty" if the user has put anything in it, and when he leaves the page without properly submitting to move on, have a popup to ask if he wants to leave the page like that, and if he clicks "yes" then empty the fields. I think you can also do some rudimentary cookie manipulation with Javascript as well.

      I'm sure there are other ways of handling this, but these two come to mind just now.
        Studying MODX in the desert - http://sottwell.com
        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
        Join the Slack Community - http://modx.org
        • 6902
        • 126 Posts
        debussy Reply #3, 14 years ago
        After a sound night's sleep and some consideration, I think we are going to go with a low session timeout (2-3 minutes) with a keep-alive javascript pinging a blank page in the background every minute or so.

        That raises another question... is there an easy way to set separate session times for the manager vs the web context? I dread having to work in the manager with a 2 minute timeout.
          • 6902
          • 126 Posts
          debussy Reply #4, 14 years ago
          For the curious... I actually ended up implementing a manual timer on the session. Something like:

          <?php

// session timeout: 3 minutes
$timeout = (3 * 60);
if ( isset($_SESSION['myTimer']) && (time()-$_SESSION['myTimer'])>$timeout ) {
   // kill session and stuff
}
$_SESSION['myTimer'] = time();


          I then made sure this little timer gets run on all the pages, including the blank page the the JavaScript pings.

          This way the timing is by and large independent of whatever the cache settings are.
            • 39932
            • 483 Posts
            Fuzzical Logic Reply #5, 14 years ago
            is there an easy way to set separate session times for the manager vs the web context?

            Absolutely! Context Settings may override System Settings. So set the System Setting high, but open the Context (click on it). Click on Settings Tab. Create a Setting of the same exact name and type. Set to a lower number.

            Note: If you really wanna break your brain with the coolness that is Settings, you can even override Context Settings by making User Settings (no, not extended fields). This way YOU can have a high setting, but everyone else has to log in after 1 minute.
              Website: Extended Dialog Development Blog: on Extended Dialog
              Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
              Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

              Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
              • 39932
              • 483 Posts
              Fuzzical Logic Reply #6, 14 years ago
              The above example is not funny on April Fool's.
                Website: Extended Dialog Development Blog: on Extended Dialog
                Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
                Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

                Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
                • 6902
                • 126 Posts
                debussy Reply #7, 14 years ago
                Context settings. [facepalm]

                Derp. ... where's my dumb hat?