You will almost certainly find that the php implementation on your webhost has a session timeout. Often this is in the range of 5-25 minutes. The effect of this timeout is to close the session (in effect , to log off any user who has authenticated) after a set period of inactivity. From the server's point of view, 'inactivity' means no changes to the session variables. Thus with the default arrangement, it is possible to be merrily tapping-away at adding text to a page, only to have yourself logged-out unexpectedly. This is because page editing doesn't in itself change the session data, so is viewed as 'inactivity' by the server, at least until you press Save.
Fortunately in Mara this is not the disaster it might seem, since being an ajax app, you may log back in without leaving the page you are editing, or losing your latest changes. However, it's not ideal. We'd like the timeout to be much longer when entering data, so as to avoid any unpleasant surprises. Conversely, though, a timeout of ten or thirty minutes is much too long if the user has in fact packed-up and gone home, but forgot to log out. In that case, keeping the session open will expose the site to various hacking exploits which rely on 'resurrecting' the unclosed session, either to the original computer or to another.
Mara addresses these issues with two siteini.php config options, timeout and keepalive. Both are in seconds.
The keepalive option causes the browser to send 'pings' to the webserver at the specified interval. These pings are sent using ajax, and are not seen by the user. Each ping modifies a dummy variable in the session, thus suppressing the server's builtin session timeout. Simultaneously, the time of the last ping event (from a specific computer) is noted on the server. Page save and similar data-transfer events also serve as pings.
The timeout option notes the time elapsed between the latest ping to be received, and the previous one. If this exceeds the set value, the server assumes that an attempt to 'resurrect' a previously abandoned but unclosed session is in progress, and logs the user out.
If the connection with the server is unreliable, some leeway is allowed in that up to three consecutive pings may be missing before the session is disconnected, provided that the timeout is not exceeded.
It's worth mentioning that the keepalive only operates on webpages open in page-editing ('admin') mode. Thus if you keep any filesystem browser tab (add image, new file, etc) open with no corresponding editor window alive, this will eventually lead to you being logged out. Though, I can see no valid reason to do this, so in practice it should not be an issue. If you do get logged out, just re-open the editor, log on and then refresh the filesystem browser.
This new timeout logic was introduced in v2.5 in response to a vulnerability discovered in the way that certain browsers handle site logins. Mara uses a session cookie as the basis of logons, which is the arrangement used by the vast majority of CMS packages. According to the php manual and most Internet standards references, session cookies should only exist until the user closes the Web browser, after which they should vanish without trace. Thus, if things work 'as the book says' then closing the browser or shutting down the computer should be functionally equivalent to logging off from the site. In fact, countless Web users have gotten used to expecting this. How many people bother to log off from a forum? A banking site, yes, you might take the belt-and-braces approach there. But a forum, no. You just shut down.
Some browsers now sport a user-convenience feature typically labelled as 'Restore my previous settings at startup.' One or two even go as far as to make this the default behaviour, such that if you don't even have to OK it. Close the browser without first clicking the X on each tab, and those tabs reappear when you next start the browser.
On the face of it this behaviour sounds as if it might have convenience advantages for some users, and at the same time it sounds quite innocuous from a security standpoint, since surely the reopened pages will demand a login if one was needed the previous time? Well, that's what we always assumed, and seemingly so did millions of other users.
As an aside, many browsers also have an option to 'remember' passwords for the sake of convenience.
Commonsense seems to tell us that the browser should never do that without asking the user, though, and in practice all do ask permission for each save of a password. So, we've gotten used to the concept that browsers don't save passwords unless we agree to that happening.
Here's the rub: The 'Restore my tabs' option doesn't just re-open the page, it also stores and reinserts all programming variables used by that page from the previous session. Since a login has to rely on programming variables of some sort or other, that means the user's login from the previous time the site was visited will also be restored, just as if that user were still at the keyboard. This behaviour has nothing whatsoever to do with the remembering of passwords by the browser, and will happen even if you disallowed that feature.
The consequence of the 'Restore my Tabs' feature is that should you fail to explicitly log off from any site before shutting down, anyone with access to the computer only has to restart it within the relatively long server timeout and open the browser, in order to masquerade as you online, and do whatever damage they like, acting in your name.
The server's session timeout will still apply, so any attempt to exploit this weakness has to be reasonably soon after shutdown. Half an hour later is likely to work, two days is not.
In the business sphere, the obvious vulnerability this exposes is where a priveleged individual 'borrows' a junior employee's computer to do some online work, for example to access the corporate bank account. He or she is then distracted, or the connection fails, and thus no logout from the banking site is performed, the browser simply being closed with the connection live . Which, unknown to the user, will activate the tab restore feature. The junior employee then only has to start the computer and browser in order to gain direct and immediate access to the corporate bank account. Any money transferred out will seem to have been the work of the administrator who 'borrowed' the computer. The time required to do this could be as little as a minute, or even less if the computer is left running, hence the five-minute or half-hour standard server timeout is no protection at all.
Worse, passwording your computer's startup may not help all that much. When network or website passwords are saved these are typically stored in an encrypted file, such that a hacker who gains illicit access to your computer, perhaps by way of a bruteforce password reset, would still be faced with the difficult task of decrypting the stored passwords. But, since the 'saved tab' data is typically stored in an ordinary file with no special protection, misuse of this data is trivially easy. Even if the hacker fails to overcome a startup password you've set on your computer, it may still be possible to recover the ordinary file containing the website session using a 'Live CD' or recovery disk to access the hard disk directly. The hacker could then transfer this 'saved tabs' data to an identical browser on his own computer. All of this would probably take less than half an hour.
The obvious implication is that with this feature lurking in most of the popular browsers, it becomes of paramount importance to log off from any website you are accessing on a shared or borrowed computer, before you shut down. However, since the action of logging off could also fail, it is advisable to then restart the browser and confirm that you no longer have access to the website in question. Any omission in this respect could have very serious security implications.
It should be noted that this issue affects all sites using session-based logon, not just Mara sites. The revised timeout feature in Mara is intended to mitigate the issue, by making it possible to set a very short timeout, without that short timeout causing too much user inconvenience. Exactly how short you make the timeout is up to you. To be completely safe against 'session resurrection' exploits it would need be no more than a few seconds, the time it takes to restart the browser after a previous user leaves the scene. From practical point of view, a minute is probably more realistic. The keepalive ping rate needs to be somewhat faster than the timeout, to allow for any inherent delays in server communication.
It really would be better if the browser programmers were to ditch this catastrophically unsafe feature altogether, or else allow some means for webmasters to detect its existence so that site editor logons could be refused until the offending option is turned off. For your bank manager the same concerns would no doubt apply, but in spades, after all online banking is a somewhat more security-critical environment than updating your website.