How do I increase the admin timeout?

Paul, you will be my hero if you succeed at that, though I must warn you that Ryan already has said somewhere or other that this will be less problematical in 2.0 (or at least I think I remember reading that somewhere or other in the last day or so, since this thread started.) I don’t know when 2.0 is due out. I do know they’re working on it.

I still believe automating authentication via cookies, as used in SMF to log you back in automatically after any length of absence from the forums, is in order here. I don’t believe any other solution will really solve the issue as robustly as a client-side cookie that allows users to stay logged in from the same machine/browser indefinitely (or as long as they specify in their preferences).

This solution really does not need to wait for 1.0 either, but yes, it will be addressed in 1.0 release by me.

I agree that a cookie is better, I was just pointing out another path.

It’s still a worthwhile backup plan for those that don’t actually want to save such a cookie on their machine. In the hypothetical Angry Client situation, saying "Ah, you should have clicked ’Remember Me’ when you logged into the site on your friend’s PC, that way you wouldn’t have lost half an hour’s typing" doesn’t cut it.

Really, to be completely robust the authentication should go Check Session > Check Cookie > Ask To Relogin Without Losing Anything.

Quote from: PaulGregory at May 22, 2006, 11:19 PM

I agree that a cookie is better, I was just pointing out another path.

It’s still a worthwhile backup plan for those that don’t actually want to save such a cookie on their machine. In the hypothetical Angry Client situation, saying "Ah, you should have clicked ’Remember Me’ when you logged into the site on your friend’s PC, that way you wouldn’t have lost half an hour’s typing" doesn’t cut it.

Really, to be completely robust the authentication should go Check Session > Check Cookie > Ask To Relogin Without Losing Anything.

Fair enough, and good points, although I might add that for really robust authentication, upon failure or successful user login, a complete chain of authentication providers could be configured, each returning an authentication result to the chain which can decide to continue or stop processing the chain on failure. This is what I refer to as federated authentication, allowing users to aggregate and prioritize credentials for site login from a sequence of various data sources, from the native MODx user system, to an LDAP repository, to a custom Oracle database, or (shudder), even a custom Access database via ODBC. Extend that same functionality to user profiles and even access permissions, add web service and AJAX access to it, and you have a very nice integration platform with a great centralized identity server.


Oh, and btw, welcome to the community PaulGregory

Quote from: kickass at May 21, 2006, 04:27 PM

Jorge, I’m sorry to report that this didn’t seem to do the trick. I just tried it, creating a new page without saving, then walking away to do other stuff for around an hour and a half. When I hit "save" it brought me to the sign in page and the document was not saved.

Kickass: Try changing this line near the top of the PHP:



The default implementation just uses whatever your server is set for timeout. This solves my major problem which is that my session is running on a shared server and gets killed by other user’s cleaning up. Now that it’s in a DB, that is not a problem.

You can set your session length here, and not worry about what the PHP INI says.

Quote from: OpenGeek at May 07, 2006, 11:39 PM

If someone could research and contribute a secure and flexible cookie-based authentication scheme to implement with MODx, that would be great. This is simply a limitation of the original authentication code which is completely dependent on the server session settings, and no one has yet addressed.

I have re-read this thread a couple of times, and i guess I don`t understand what you`re asking for here.

What`s not secure or flexible about the current modx session support? Isn`t it a good thing that the sessions are based on "standard PHP" servers session settings?

My understanding is this: When you log into modx, the server generates a random session key and puts it in a cookie that is sent to the browser. Each time the browser makes a request, it sends the cookie (with the random session key) to the server. The server looks-up/stores data associated with the random session in a file (or in the DB if you use my script).

So here are what I see as security issues:
1) It seems difficult for anyone to guess the random session key of another user. Assuming they’re really random.

2) All the session data is stored in the server, not in the cookie. So looking at the cookies in the browser cache isn’t a security hole.

3) On a shared server, all the session information is in a common directory (as long as you use the defaults). In this case, other users of the shared server could look in the files in that common directory and see session info. It seems that changing settings to store the cookies in the DB solves this nicely.

4) The server timeout (for security reasons) can be configurable. In regular MODX you have to change PHP_INI. In my script, you can just set a constant (or read it from DB or whatever). When it does timeout, the session ENDS. This is a good thing. It makes it hard for someone to walk up to a browser that has just been closed (in a hotel or internet cafe) and reuse the session. UNLESS THE SESSION IS REALLY LONG.

To address #4, it sounds as if (at least one person) asked for: Allow short sessions (to address the internet cafe issue), but keep the connectoin alive via periodic AJAX "pings" until the user closes the browser. Then since there are no more pings, the server session would soon timeout. I guess this is because the onClose event is unreliable (at least on safari).

What other configuration and flexibility do you have in mind? What do we need to add here?

-- Jorge.

One of the things I fixed recently has to do with a session script I implemented that keeps the current session alive indefinitely till you either close the browser or lose connectivity with the server. Works great and is incredibly simple thus doesn’t put a tax on your server. However, I screwed up one line and didn’t put in the proper relative path to the javascript file that calls it. If you go to /manager/frames/1.php, change line 18 to this:



After this change, clear your browser cache and visit the manager. Do a few things and then keep the browser window open. Try coming back to it in 30 minutes...which is enough time since most servers are set to timeout a session in 15 minutes or less. You should be able to continue doing things without the manager kicking you back out the login screen.

Let me know if it doesn’t work for ya. Been testing it myself and it appears to work great!

Jeff

Quote from: jorge at May 24, 2006, 02:45 AM

I have re-read this thread a couple of times, and i guess I don`t understand what you`re asking for here.

What`s not secure or flexible about the current modx session support? Isn`t it a good thing that the sessions are based on "standard PHP" servers session settings?
...

What other configuration and flexibility do you have in mind? What do we need to add here?

-- Jorge.

I’m talking about a client-side cookie, which stores encrypted user credentials (and IP address, or any other unique information that can help prevent XSS attempts to steal the cookie data), which will allow the MODx user session to be recreated on the server on the next request after the server timeout occurs, indefinitely, or within an amount of time specified by the user. This can provide persistent authentication as long as the cookie is not cleared on the client.

This does not of course actually extend the server-side session, but it allows me to access these forums without ever having to actually type my username/password, and same with my Basecamp project management website, and a host of other web sites I visit regularly.

This does not of course actually extend the server-side session, but it allows me to access these forums without ever having to actually type my username/password, and same with my Basecamp project management website, and a host of other web sites I visit regularly.

So you want single-sign-on like Microsoft Passport? And you want it to work with websites that aren’t MODX based?

Quote from: jorge at May 24, 2006, 10:22 PM

This does not of course actually extend the server-side session, but it allows me to access these forums without ever having to actually type my username/password, and same with my Basecamp project management website, and a host of other web sites I visit regularly.

So you want single-sign-on like Microsoft Passport? And you want it to work with websites that aren’t MODX based?

No that’s a separate discussion that goes back to the chaining of various authentication providers; I’m simply talking about the individual mechanisms on those sites that allows you to automatically login when you return to that site.