Logging into Manager: session vs. cookie

Hi,

I would have wished that when logging into the manager, if I check "Remember Me", next time I come back to the manager I would not have to authentify again. However, that’s not the case: if I close my browser and open it again, I have to authentify me again.

I checked the code, and if I understood well the code, the persistency of user data is done through session, not cookies. Is there a reason for that ? is it more secure ?

I don’t know exactly how sessions are managed by the server. One of the back-end user of MODx had a pb: he edited the content of a page for a long time (~ 2 hours), and when he clicked on ’save’, it did not work and he get back to the authentification page. So how a session can be ended by the server ?

Tristan

I have the same problem with the manager login on Mac/Safari. Should be resolved for the next release though.

aaaah, good news !

another reason to be so impatient about the 0.9.2 release

Most php installations have a time limit on keeping a session that is inactive. By default it’s something like 22 minutes. Every few page requests, the server checks all the session files, and any that haven’t been updated in that time get deleted.

One solution is to have your site’s session files stored in a different folder than the default (usually the server’s shared tmp directory). If you do that, however, you need to maintain your own "garbage collection" of old sessions files.

I believe what needs to happen is the client-side cookie should allow the session to be re-instantiated if the server kills it, so our ability to stay logged into MODx is not dependent on the server-side session handling.

Hm. Have you taken a good look at a dump of a busy SESSION file lately? Usually the cookie associated with a session just contains the session filename. Since stale session files are physically deleted, all session data would have to be maintained in the cookie being sent back and forth with each page request.

What I would really like to see is MODx moving to storing session data in the database instead of the filesystem. It’s a lot more secure, for one thing. Which is one thing against maintaining a session entirely in cookies; it’s far too easy to intercept a cookie and hijack an active session. Having the session data in a file in a shared public filespace such as /etc isn’t all that secure, either.

So how does the next MODx release will affect the session management ?

Tristan

Quote from: sottwell at Apr 10, 2006, 07:54 AM

Most php installations have a time limit on keeping a session that is inactive. By default it’s something like 22 minutes.

You were right, Susan, session.gc_maxlifetime is set to 1440 seconds (24 mn) on my host (ovh.com). That’s very short when editing big documents.

So I modified config.inc.php:



With this, the user has 24 hours to edit a single document, that should be enough !

Tristan

That probably will not work on a shared hosting system. The garbage collection works for the entire shared /etc directory, so every other user on the system who is using the default system will be triggering the system-wide garbage collection. Your files get deleted along with everybody else’s files. PHP doesn’t have any way of determining that your session files are any different from everybody else’s.

I’m using a shared hosting system :’(

I tried with smaller values (60 seconds) and it worked (after 60 seconds, I get back to the login screen). So I figured it out that it should work for bigger values ...