We have a default short session timeout of 10’ because we want to be sure that it is actually the real user who is performing the request (and not someone who has get access to the user computer). The short session timeout and refresh tries to verify the continuity of the usage of the application.
But this has the annoying effect that user needs to enter often his password even to perform request with low risk (like reading a party).
Indeed ideally, the level of trust in the user authentication depends of the request. For example, posting an invoice requires more trust than searching for a party. So it will be good to have two timeout, a long one used for low risk requests and a short one for high risk requests.
Proposal
We increase the default timeout of the session to a higher default value (ex: 30 days).
We add a second timestamp on the session Model which is set when login and refresh on each request only if the last timestamp was before a new timeout. This new timeout is part of the configuration and is set to 10’ by default. We define on RPC if the request must enforce the short timeout session. If it is the case and it is a session, then the second timestamp is checked in the dispatcher and aborted by UNAUTHORIZED.
We should activate this enforcement mainly on button which involves money like posting invoice or move, validate payments, sales or purchase.
I fail to see the real benefit of this feature for the following reasons:
Who will decide about the importance of the modell accessed? For instance it could be relatively uncritical to show party data to an unrelated person, but those data are quite sensitive data in a hospital.
It could be quite surprising to the user, if he is able work on the client, but unexpectedly runs into a session timeout when accessing e.g. an invoice.
I’m not very fond of this proposal. I think the most probable misuse of an open session is stealing information via export or Ctrl+c and this wouldn’t protect against that.
And as Mathias said, it’s going to be surprising by the user to see that she was working without problems and was asked for the password at some point.
I think we have a misunderstanding here. We are not talking about data access right, there is already a layer for that.
So what is the problem. We have already unexpected session timeout. And it is a pretty common design to have to re-validate some actions with password.
I do not see the relation with the topic. The current session management does not prevent against that neither… When a session is stolen, the thief has of course access to what the session allow to have.
So there will be no default usage of this feature in the standard modules?
I think we are talking of access to user sessions, right? When getting to an abandoned machine/terminal with an open session you get all the access pemissions of the running session. So session access permissions come even before data access permissions.
JFTR: That’s exactly the point why staff working on POS (e.g. in restaurants) are supposed to carry their key/chip/card/whatever directly with them and their session is locked as soon as they leave the terminal.
The session timeout as is is not unexpected. But with the current proposal it will be at least surprising, if the user has to re-validate certain actions sometimes, but sometimes not.
In issue7568, I have implemented a slightly different version of the proposal. Instead of keeping a long timeout for the default session, I choose to use a fixed age for the session which is a recommended practice from OWASP.
I have use this mechanism when user set preferences which avoid custom code. But once the design is fixed, we should implement on all sensitive operations.
You had asked the community about your proposal of double session timeout, and the response was negative (adding my 2c - I don’t see a benefit of this either, it just adds complexity).
Despite the clear vote of the community - and I see well-known long-time contributors here - you continue implementing the ‘feature’. Just for my curiosity - why do you ask if you are not interested in the input?
This is needed to have a workable Real-time notification
The only concern is about the “surprising” effect which is very minor concern (and probably does not exist in the average user). And people who wants the previous behavior can still put an maximum age for a session to 10 minutes. (But almost all the installations, I saw, have increased the default timeout to at least hours)
But this implementation improves the security thanks to the fixed age of the session.
On second thought, I think most larger sites are already doing that. For example, by requiring password only if the user has a suspicious behavior or when accessing most sensitive data.