John D Wells

I build websites with HTML, CSS, jQuery, PHP, ExpressionEngine & CodeIgniter.

Proud co-founder of the kick-ass, London-based creative agency One Darnley Road.

© johndwells

Stay Up Forever: Take control of EE’s session time limit (maybe)

ExpressionEngine’s hard-coded, 1 hour time limit for CP sessions has always been a real nuisance - frustrated clients have asked repeatedly for it to be extended. I’m cautiously releasing an add-on that finally grants control of this limit, but I’d appreciate some help to determine its usefulness & effectiveness.

Published:
Jan 23, 2011
Filed under:
EECMS
Comments:
7 - add yours

Is all of this really necessary?
Not entirely: You can set the Control Panel Session Type to 'Cookies Only' and avoid all of this - plus gain the "keep me logged in" checkbox on login screens.

Update 2: NEVERMIND ALL OF THIS MALARKEY. As of EE 2.2.somethingorother, there are two new hidden configuration variables that allow you to control the session length of both CP users and front-end visitors. See User Session Length and Control Panel Session Length for more.

Update 1: Initial tests, with the help of some in the community, find that "forever" might only be 4 hours. The reason behind is mentioned in the "Potential Pitfalls" section below, and further discussed in the Comments section. Still, I'd appreciate more input & feedback.

As this EE Wiki entry explains, it is not considered possible to increase EE's session time limit without hacking the core. That's no good of course, so until now I've always considered this task to be off limits.

Then this past weekend I began researching possibilities of overriding/extending EE's core libraries. It's a somewhat controversial topic, and I'll save my musings for another day. But the upshot of all that tinkering was that I discovered it's actually quite simple to modify the hard-coded session time limits, by way of the ever-popular sessions_start hook.

I don’t like it when people tell me I can’t do something I want to do.

- Isaac Raways, author of the Wallace extension

When sessions_start hook is called, it's passed a reference to the EE_Session object; and at least until EllisLab starts protecting class properties (a distinct possibility now that PHP4 support has been dropped), this means it's a piece of cake to overwrite what's in place:

// called by EE's sessions_start hook
function sessions_start($sess)
{
	$sess->cpan_session_len = 12345; // default is 3600, or 1 hour
	$sess->user_session_len = 67891; // default is 7200, or 2 hours
	$sess->session_length = (REQ == 'CP') ? $sess->cpan_session_len : $sess->user_session_len;
	return $sess;
}

Could it really be that easy? From my initial tests, yes, yes it is that easy. So I've turned it into an add-on: Stay Up Forever.

Right now, I'm considering this an early beta release; it's the sort of thing that could, if misused or broken, permanently lock you out of the CP and wreak general havoc.  So I'm hoping there will be some clever/brave souls out there willing to give this a spin.  I'm also hoping anyone from EE's Core team might be able to highlight any potential pitfalls this add-on might raise.

Possible Pitfalls

For example: I'm aware of EE's XID hash, for use with secure forms, and these too have a hard-coded shelf-life: 14400 seconds or 4 hours.  Initially this had me worried that a CP session set to expire beyond 4 hours might result in lost form submissions, but I found that the XID hash is periodically updated via javascript (read line 13 of themes/javascript/compressed/cp/global.js).  However I don't know if this interval is effected by sleeping/waking your computer, so this is a possible gotcha.  I'm keen to hear what others think.

Current Features

Right now, Stay Up Forever is about as simple as it gets: install the extension, go to the settings page, and enter how many seconds you wish the CP and non-CP sessions to last. If you leave either value blank, the defaults will be used.

Default values will also be used if the configured time limit is set below 60 seconds; it's a safety measure to ensure you always have a minimum amount of time to log in, should anything go totally haywire.

It is NSM Add-on Updater compatible, so you'll be notified of updates (why on earth is this not already part of core?).

Potential Features

So far I can think of a few features/improvements:

  1. EE1x support
  2. Human-readable settings (e.g. '3 hours', '1 day', etc)
  3. Settings per member group, as suggested here
  4. Better Settings form, instructions etc

Join the Party

That's all for now: drop a comment below if you have feedback or ideas.  And head over to the downloads area to get your copy now.

Published:
Jan 23, 2011
Filed under:
EECMS
Comments:
7 - add yours
 

Have your say...

I’m happy to check this out. This has always been an annoyance for me as well. As you can probably guess, I feel strongly this should simply be a setting in a site’s config file. I’ve installed your plug in, set it for a 24 hour session. I’ll let you know what I find out.

  • #2
  • On 05:20 PM, 24/01/11
  • From London, UK
  • John D Wells said:

Nice one John, I appreciate your help.  Looking forward to hearing how you get on…

Cheers

The addon kept me logged in longer than normal, but didn’t keep me logged in the 24 hours I expected. I had 86400 in the addon’s settings. 24 hours, right?

  • #4
  • On 10:45 AM, 25/01/11
  • From London, UK
  • John D Wells said:

Yep, 86400 is right - I set mine last night for the same, and just checked 10 hours in and I was still logged in (however I didn’t try submitting a form, just clicking a nav link).  Approx how long did it keep you logged in for?  Did the little ajax slider appear to tell you that you were logged out?

Yes, the ajax alert came up. What I did for my test was to open a new entry page and basically leave it sit there. I checked it occasionally as the day went by. I would guess I noticed the ajax logo out message about 6 hours in. Any thoughts?

  • #6
  • On 12:59 PM, 25/01/11
  • From London, UK
  • John D Wells said:

OK, I’ve read through the JS code a bit more, and this is what appears to be going on:

As I mentioned above, there is an XID hash key that is given it’s own hard-coded time limit of 14400, or 4 hours.

Turns out that the ajax logout form is triggered to be shown whichever happens first: either the XID_TIMEOUT runs out or the SESS_TIMEOUT does.

In reality, this means the ajax logout form is incorrect, as you should still be logged in - did you try hiding the form, and clicking somewhere else on the CP?  I’m willing to bet you won’t be kicked out to the login page.

Frustratingly this is not something I can see getting around without modifying the core js.  This might mean that “forever” really means “up to 4 hours”.  Hmmm.

 

I really was logged out. After I got the Ajax form, I hid it and then clicked the home icon to go to the front of the control panel which redirected me to the log in form.

On the EE site I’m developing now (not the one I tested this on), I’ve set the control panel session and user session to use “cookies only”. This lets me stay logged in all the time but I won’t leave it this way when I take it off my development environment.

Anything else you want me to try on my end that will help out?