How do I increase the admin timeout?

So Jeff, what you are saying is that the fix for the admin timeout issue has been sat on our servers all this time - and even key team members didn’t know it was there? We just need to fix a simple oversight?

Wow.

May I point out that there are two other places in that file that will need changing - ie the script calls in the other two manager layouts, at around lines 43 and 113 if I remember rightly.

Can someone please moderate out the discussion of authentication methods to a separate thread, so that people can get to the solution quicker?

Quote from: PaulGregory at Jun 07, 2006, 12:32 AM

So Jeff, what you are saying is that the fix for the admin timeout issue has been sat on our servers all this time - and even key team members didn’t know it was there? We just need to fix a simple oversight?

Wow.

Actually, pretty much any key member would know that it was there since every change to the core code gets logged. Thus the changes I made that added this functionality were known. What wasn’t known was that the path was wrong. Even I didn’t catch it till someone complained about it. But, hey, nobody’s perfect. Mistakes are bound to happen and bugs will continue to get reported.

Quote from: PaulGregory at Jun 07, 2006, 12:32 AM

May I point out that there are two other places in that file that will need changing - ie the script calls in the other two manager layouts, at around lines 43 and 113 if I remember rightly.

You may point it out if you’d like...however, keep in mind that the other manager layouts are going to be deprecated in the next release. Thus there’s no reason to worry about it. Lots of exciting stuff coming down the pipeline!

Quote from: PaulGregory at Jun 07, 2006, 12:32 AM

Can someone please moderate out the discussion of authentication methods to a separate thread, so that people can get to the solution quicker?

Good call! Yes, I do believe that this other discussion needs it’s own thread.

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! Smiley

Implemented on client site. Cleared browser cache, waited over 30 minutes, then clicked a menu option in manager. It booted me back to sign-in. Browser is Firefox 1.5.0.4.

Quote from: kickass at Jun 10, 2006, 06:16 PM

Implemented on client site. Cleared browser cache, waited over 30 minutes, then clicked a menu option in manager. It booted me back to sign-in. Browser is Firefox 1.5.0.4.

Did you fix the path to the script file in the frames file as directed? You actually have to fix it in three different places. Also, keep in mind that the script is also co-dependant on your server’s capabilities. All it does is call a simple PHP script about every 60 seconds that makes sure the session is still started. If your browser chokes on getting the script via javascript then it’ll fail. Same applies to the server...if the server fails on properly parsing the PHP script and sending back the right response then it’ll fail.

So the question is...is it a bug? Probably not. I’ve tested it again over the weekend a few time. One time it failed but succeeded numerous times after that. Hell...I even kept a brower window open for a little over a day and it still worked! How weird is that? The real question is: Can this be relied on? Err...not 100%. Again, timeouts will happen and will occur now and then. It’s still recommended to save your document now and then or write it offline first then paste it into a new document.

Jeff

Google pagecreator uses AJAX to periodically save the document. If AJAX fails to save the document, there will be an error visible on the page and a link to reopen the connection. When that link is clicked, it uses ajax to recreate the connection and after that user can save normally. No information lost. If user is going to leave from the page to for example main menu and the page was not autosaved, there will be a javascript alert saying that the document is not autosaved and usually it means that the connection to server has lost and need to click the reconnect link..

I don’t know how this all is implemented and how it would fit to MODx, but I noticed that someone allready made an ajax enabled saving for documents and the like.. could it be refined to be fully working solution and with an option too to enable auto saving via ajax while writing a document. And if ajax save fails, there would be a link to recreate the connection / session (or automated) and documents can be saved without information loss..

I noted that the auto save feature has been discussed here too, but I don’t mean that it would be forced to use autosave. Just an ajax enabled saving of documents and if save fails, possible to recreate connection/session via ajax without the browser refreshing at anytime.

So... Can it be done? I noticed that there’s some issues with character encodings maybe when using ajax, is this true?

That’s a good question. Yeah, we need to implement a more solid solution to the session problem when saving documents. I’m all for the idea of using AJAX to check for a session when a document or setting is saved or doing anything else for that matter. It would have to be implemented in such a way so that just about any link or form that triggers functionality would check for a current session. That way, if a session doesn’t exist, then a simple AJAX styled prompt would ask you if you want to log back in and then just recreates the session and continues doing what it was supposed to be doing. As we go about redoing the manager itself, we’ll explore that and see if we can implement a more worthwhile solution. Hmm...guess I need to put that into the bugtracker as a feature request so I don’t forget.

In regards to the AutoSave feature...yeah, that’s been mentioned too and I think is already in the pipeline. Don’t know the status though or if it’s been implemented yet. Lots to think about!

Jeff

Quote from: Bravado at May 24, 2006, 12:21 PM

If you go to /manager/frames/1.php, change line 18 to this:

	<script language="JavaScript" src="media/script/session.js"></script>

This bug can cause the site’s 404 page to be returned instead of the .js file, requiring a document to be parsed and uploaded, even though it’s never seen or used by the client! So every time you use the Manager it’s adding another page of overhead. (not to mention causing javascript errors)

Quote from: sottwell at Jul 27, 2006, 03:41 AM

Quote from: Bravado at May 24, 2006, 12:21 PM

If you go to /manager/frames/1.php, change line 18 to this:

	<script language="JavaScript" src="media/script/session.js"></script>

This bug can cause the site’s 404 page to be returned instead of the .js file, requiring a document to be parsed and uploaded, even though it’s never seen or used by the client! So every time you use the Manager it’s adding another page of overhead. (not to mention causing javascript errors)

Well spotted. That would pretty much by a "reason to worry about it", rather than just a mild annoyance, and I’ll go round updating all my sites with this fix. I’ve pointed it out to someone whose heavy-404 page overhead was potentially causing a problem.

(And yes, I’ll have a go at splitting this into two threads - one about fixing the existing session keep-alive and the other about ways of keeping a session alive.)