GUI "edit" page silent timeout long before session timeout

[stilez]

If I leave (for example) the "edit firewall rules" and "edit file" GUI pages open in my browser while I'm away from my desk, and then come back a little later -

• The edit firewall rules page continues to be usable as if I hadn't been away, however long it's been

but

• The edit file page lets me type, but silently freezes and fails to work when I try to interact with the server (ie load/save/browse a file). This seems to happen whatever session timeout I set in User Manager.

This isn't desirable behaviour for me, and I'd like to know what causes it. I originally suspected something CSRF related but if so couldn't understand why most pages (and their user input) aren't affected but the Edit Files page is so greatly affected.

I'd really like to learn what's going on.

Is it possible to change this behaviour or modify the timeout (or whatever it is that's affecting the "Edit File" page of the GUI)?

[jimp]

Other pages submit in a traditional way, Edit File uses AJAX. That probably explains the difference. It won't kick you back to a login page if your session times out and then you try an AJAX request like it would on a page load/POST.

[stilez]

Thanks Jim. I added an error handler into the page's ajax code (it didn't have one) which confirms the issue, much like you said. But some behaviours look like they could be bugs, or undesirable/questionable, so I filed the other things I found on redmine.

[stilez]

@jimp - Incidentally, quick bugfix needed (needs someone more experienced due to security-related implication).

In guiconfig.inc, csrf_startup() references $config[] to determine if a timeout is defined and set a matching timeout for the csrf token. it looks like $config[] isn't available nor accessible as a global within csrf_startup() when it is called. So the test used to set $timeout_minutes at about line 30 of guiconfig.inc always fails.

Any chance of posting a quick fix for that, as it's security related?

[jimp]

It's a bug but the CSRF magic default timeout is less than hours (2 hrs vs our 4) so at least in the default case it's actually more secure, not less. I'll push a fix shortly.