Administrator login/session length

[dbmorgan]

I own a web site and perform most of the editing from my home office.  For some reason I am unable to set a log-in time that allows me to remain idle for more than a few minutes before I am required to log in again.  This can be really exasperating if I am making some major changes on a content page and go to save the changes and then am directed back the log in page (and losing all of the changes made).  I am not is a public location so I really would like to be able to stay logged in for hours rather than minutes.  I have tried entering different numbers for the session lifetime but nothing seems to work.

Is there a limit on how long an administrator session can be?  Any ideas why I get bumped off after only 3-5 minutes on inactivity?

Bruce
http://www.pepper-passion.com

[rjs]

Set your session length to 10000. That is what I've done for the longest time.

[dbmorgan]

I have tried using all sorts of large numbers with no effect.  I am currently set at 3600 seconds (which is one hour) and I do not get a fraction of that.  I am wondering if it might have something to do with the setting of the time zone and the time zone offset in the configuration.  I am located in the Pacific Standat Time and I was told by my web hosatinv company that the server is in Texas so I set the offset to -2 and the correct local time is displayed.  The country locale is set at "en_US".  Is there soemthing else I may be missing?

Bruce

[rjs]

Not that I'm aware of. Sounds like you are on top of it. I'm hoping the situation will be looked into by the dev's. There are quite a few "too many logged in users, not showing correct logged in users, keeps logging me out" threads. Between this issue, and the security issues of late, it must be a full time job for the devs. I personally wish we had a "bypass administrator" login based on IP and other criteria. Something similar to firewall/router rules. A configuration form someplace that was looked at for admin pass this IP, allow.

Even a 3pd hack for this would be nice. It opens up other issues that are taken care of by the httpd conf and not allowing access except based on IP.

[leroy]

I too am very frustrated with the short session length. There has to be some kind of hack that will allow an administrator to stay on.

[davidrrm]

Are you logging in to the administrator section? Or the front end? to do your editing.

[stingrey]

The admin login is hardcoded to an inactivity period of 1800 seconds.

So after 1800 seconds of inactivity you will be logged out.

[dbmorgan]

Pardon me but that is one of the dumbest programming decisions I have ever heard of.  I and hundreds of other have been fighting this issue for months.  What is the use of having a selectable session time limit without notifying users that the number they might select is limited to a very short 30 minutes?  I personally have wasted hours on my own web site due to the fact that I might spend 30+ minutes on a single page of content and then have all of the work lost when I hit the save button and am directed back to the admin login screen.

I do my work from a private location and am frequently interrupted by phone calls and other matters. I would prefer to have my login be 8 hours or more so I would not have to login more than 10-15 times a day to get my work done.  The seltable seesion limit would be just fine without any limit hardcoded in.  If you must have a limit, increase it by a factor of ten and for God's sake make that hard limit known to users in the configuration panel.

Bruce
http://www.pepper-passion.com

[leroy]

Seems to me that Joomla is not a useful management tool unless you can keep a session.

I just hacked administrator/index2 and index3 to give me 3 hours before it forces a timeout.

I also hacked joomla.php to not kill a session until a user's browser closes.

We will see how this goes.

[dbmorgan]

If you are still up three hour later I would love a copy of that hack.

Bruce

[stingrey]

Pardon me but that is one of the dumbest programming decisions I have ever heard of. 

Well to be honest I myself was unaware that this was hardcoded into the code and had always assumed that the session time setting in global config controlled the backend session length as well.
We have corrected the terminolgy in 1.0.8 for this setting to make it clear that it affects frontend session time only.

At who knows how many thousand lines of code I thought I was aware of most areas - but session management was something I have never explored as it had never been under my area of 'control'. 
As one (like all Joomla! devs) who do this in the hours outside of 'normal' work hours in that rather rare commodity called `free time`its near impossible to keep an eye on every single issue and still have a somewhat normal life and that other rare commodity called `sleep` - last time I checked I think my clock showed 5am whats it in you part of the world

[stingrey]

I also hacked joomla.php to not kill a session until a user's browser closes.

This problem was due to an only recently discovered bug whereby the frontend session clearing mechanism
(to kill frontend sessions) was not making any distinction between frontend and admin sessions and thus was clearing backend sessions as well - this will be fixed in the upcoming 1.0.8


These a similar session issues are discussed here:
http://forum.joomla.org/index.php/topic,34620.0.html


BTW it should be noted that the longer sessions are active, the higher the possibility that they might be captured and misused - hence the historically short session lengths utilized

[leroy]

I appreciate there are security concerns about leaving sessions open. I will probably experiment until I find the right balance of session time for me and my users.

The best thing, I beleive, is to distinguish between admin and user sessions and not kill admin sessions, or provide a configuration-level distinction between them. I will probably put that in my hack but it would be great to have this taken care of in an upgrade.

Apparently, some of us use joomla as an admin tool and we want to keep it up all the time. I manage several e-commerce sites and use an admin site built on customized joomla components to do maintenance, admin, and diagnostics on the other live sites. I need to keep that site up.

Stingray, et al, thanks for the response. Whip that dev team into shape. Soon as I make some money I'm going to send them some pizza. 

[stingrey]

The best thing, I beleive, is to distinguish between admin and user sessions and not kill admin sessions, or provide a configuration-level distinction between them. I will probably put that in my hack but it would be great to have this taken care of in an upgrade.

It has already been corrected in 1.0.8 SVN.
So frontend session cleaning only affects frontend sessions and backend session clearing only affects admin sessions - where previously neither clearing mechanism (front or backend) differentiated between each other.

Apparently, some of us use joomla as an admin tool and we want to keep it up all the time. I manage several e-commerce sites and use an admin site built on customized joomla components to do maintenance, admin, and diagnostics on the other live sites. I need to keep that site up.

Yes I am seriously considering adding a backend session time configuration as it kinda annoys me to now that I know its hardcoded and its affected other core member detrimentally - like our Doc team members - already.

[leroy]

Stingray, you say that 1.08 cleans the backend and frontend separately. Right now, administrator/index.2  appears to me to clear out any session that is over 30 minutes. Am I right? So in 1.08, it will only clear out ADMIN sessions over 30 minutes? I assume the frontend timeout would still  be handled by the value by the current config parameter.

If I am understanding you, the separation is a good thing, but we still need a way to set the length of the administrative timeout at the configuration level.

[stingrey]

Stingray, you say that 1.08 cleans the backend and frontend separately.

Correct

Right now, administrator/index.2  appears to me to clear out any session that is over 30 minutes. Am I right?

Correct, this was a bug that was only pointed out to me recently.  Which is now fixed in teh upcoming 1.0.8

So in 1.08, it will only clear out ADMIN sessions over 30 minutes?

Correct.

I assume the frontend timeout would still  be handled by the value by the current config parameter.

Correct

[stingrey]

If I am understanding you, the separation is a good thing, but we still need a way to set the length of the administrative timeout at the configuration level.

It is something I am serirously considering.

Strictly speaking the work on the stable code base 1.0.x is only supposed to be Stability & Security fixes.  This matter is strictly speaking not a bug (hardcoded 30 min Admin session timeout) as it is working correctly - such a change would be feature addition.  However it certainly poses a usabiity issue as people have pointed out here and in other posts

[dbmorgan]

I am not sure if I really know the difference between the back end and the front end but if someone has a hack that will keep the administrative door pried oipen for longer than 30 minutes I sure would like to try it.

As for the next release they are too frequent and too buggy.  I tried to update from 1.0 to something more rrecent and my site was down for two days.  I applaud the effort to get a stable release but it really is splitting hairs to try and determine if a useful admin login time represents a bug fix or a new feature.  It may not have been a bug but it was a huge mistake and the faster it is undone the better.  It is broke so I hope you will fix it.

Bruce

[stingrey]

I applaud the effort to get a stable release but it really is splitting hairs to try and determine if a useful admin login time represents a bug fix or a new feature.

For a small item like this possibly. 
But where do you draw the line, between adding something to the stable branch as compared to the development branch

New features have greater chances of creating new bugs.  Its hard enough to fix just bugs and trying not to have a fix create a new unintended bug.  Then have a completely new feature than sprouts a whole branch of new bugs.

[leroy]

Here's the hack. It is extremely simple. It worked today for me.

it is in administrator/index2.php

// timeout old sessions
//$past = time()-1800;  // this is the old line, 30 minute bladerunner effect
$past = time()-10800;  //this is the new line,  10800 seconds ( 3 hours ?) seemed like a nice number
$query = "DELETE FROM #__session"
. "\n WHERE time < '$past'"
;

There is a similar snippet in index3.php
The files are so short you won't have any trouble finding it.

It is not clear to me if the front end timeout set in global config will affect the admin login timeout. I guess not, but if it does, that might be the limiting factor. You could set it high or disable it entirely. It's in includes/joomla.php , line 600 and change. search for session timeout.

Stingray is right about there being security issues and there is always the possibility of unintended consequences. Use a condom!

[pangea33]

There is also a session lifetime setting in the php.ini file on your webserver. I suspect it's safe to assume that this value will override any configuration settings within Joomla. Mine was set to 1440 seconds after fresh install, which is only 24 minutes.

Lines 989-991 (approx) in php.ini:

Code: Select all

; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440

[leroy]

I wonder if the php session lifetime is being set by joomla. Can any developers tell us the relationship between joomla and php sessions?

I have not changed my php.ini file from 1440 and I'm getting longer than 24 minutes.

[pangea33]

Bear in mind that this represents time of inactivity. Every time you load another page, the timing on your session scope should be refreshed. If you're actively navigating your site and are getting logged out, there is a much bigger problem present.

[stingrey]

I wonder if the php session lifetime is being set by joomla. Can any developers tell us the relationship between joomla and php sessions?

I have not changed my php.ini file from 1440 and I'm getting longer than 24 minutes.

In 1.0.x Admin Backend sessions are handle by PHP Sessions and verified via entries in the jos_sessions table.

So a PHP Session will only be considered valid if there is a corresponding valid entry in the jos_sessions table, before you can login.
Without a valid PHP session, you cant login
Without a valid entry in the jos_sessions table you cant login.
You need both to login - this for security purposes.



The PHP sessions is set to expire when your browser closes - it has not fixed expiry time.
Now in 1.0.7 the entries in jos_session are cleared after a fixed inactivity time of 1800 seonds - in 1.0.8 you will now be able to set this value.

However, due to a bug in 1.0.7 it was possible that the frontend session clearing mechanism could also clear admin session times - this has been corrected in 1.0.8  So for example if frontend session clearing is less than 1800, it could clear your backend session incorrectly.

So if the entry in jos_sessions is removed you are logged out



However as pointed out there is also server level clearing mechnism for PHP Sessions - which are stored in your /tmp/ path - which is why it needs to be writeable.  In 1.0.7 the core does not adjust this number.  By default the value is 1440.  Now through a percentage based controlled system the PHP Session garbage cleaner could also clear you session entry before the fixed 1800 time.  Hopefulyl be now setting this time within the core this is less likely to happen.

But now even with the fixes and changes to session admin management it is still possible that if you set the session logout time to 8 hours, the Server level PHP session garbage cleaner can still kill your sessions, please read here for more on this isse:
http://www.captain.at/howto-php-sessions.php

[stingrey]

So what is the bottomline in 1.0.8?



Hopefully all the above issues will have been fixed and resolved.

I have now added a new Global Configuration value to allow people to set the amount of inactive time before a session is expired.
Fixes conducted to bugs in the code, should mean that sessions shoudl now correctly stay open for the period people set, instead of arbitrarily ending unexpectedly. 


I will blog about this shortly.

[leroy]

Thanks for your work on this, Stingray.

My understanding now is that the joomla session-timeout issue has been resolved in 1.0.8, at least the front and back-end session timeouts can be set independently.

But there is still the problem of PHP clearing out a session prematurely,  through its garbage collection routine. This sounds like more of a problem for the longer admin session because the PHP garbage collector is a statistical process and can't distinguish between front and back end sessions.

If this is a problem for longer admin sessions, one could increase the session.gc_maxlifetime parameter in the php.ini file. But this could  increase the persistence times of all session garbage and possibly chew up disk space for sites getting lots of front-end traffic. Alternatively, a separate directory and gc_maxlifetime could be designated for admin session files to hide them from the garbage man. I don't know if this could be done at the component level, but it seems to me that it could be done at the core.

I don't know how much of a trouble this garbage-collecting is for my admin sessions.  It is easy to be wrong about this stuff when you have a small brain.

For the time being, I am going to increase my gc_maxlifetime parameter to an hour and see how that goes. With the changes you have made to 1.0.8, this may give me the slack I need.

I know the dev team has other priorities, but persistent admin sessions  would make my life easier.

[stingrey]

But there is still the problem of PHP clearing out a session prematurely,  through its garbage collection routine. This sounds like more of a problem for the longer admin session because the PHP garbage collector is a statistical process and can't distinguish between front and back end sessions.

Frontend session management does not use PHP sessions, but rather a combination of cookies and the jos_session table.
Thus is not affected by the Server Level PHP Session garbage cleaner.

In 1.0.x Joomla core only uses PHP session for backend admin.

[stingrey]

I know the dev team has other priorities, but persistent admin sessions  would make my life easier.

The only way this would be possible (due the PHP Sessions garbage routine) would be via cookies and the jos_session table like the frontend, however this method is far less secure than the PHP session method.

This is because cookies can easily be intercepted and also faked.  For example there are extensions for firefox that allow you to create cookies manually.
So persistent sessions times is not possible without opening your Site Admin to serious security issues.

[dbmorgan]

I applied the hack suggested by Leroy and it does not seems to work.  Would this imply that I need to address something at the server level by contacting my web hosring service?  I understand there are some security issues here but I wonder hoiw much worse things would be if the timeout window were widened from 30 minutues to three hours?  I would like to do this and if you have any further suggestions I would like to try them.  BTW, I assume that by backend you mean administrative, with front end relating to users/consumers.

Bruce

[Darren996]

Hi,

I still have this same problem on 3 of 4 of my websites.  Strangely one website, my test site, I can edit a document and walk away for several hours, come back and still save it.  The others, no way.  I get a permission error and the changes are lost.  I have checked the settings between all of them and don't see the difference.  They are all on the same server.

I am not complaining mind you.  I would like to help if I can. 

Anyway, I would like to be able to change the session time out for normal users to 0 so the validated user is not timed out as long as they keep the browser open.  I would have to hack the core though cause the time() is added to the timeout value to determine cookie expiration.  Does that make sense?  If the timeout value is zero then set the cookie timeout value to zero? 

Is this secure?  I don't think it's unsecure.  I have to balance my IT security with my personal security as some of my users would like to lynch me for the timeouts. 

Thanks,
Darren