Double session timeout

(Cédric Krier) #1


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 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.


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 an aborted by UNAUTHORIZED.

We should activate this enforcement mainly on button which involves money like posting invoice or move, validate payments, sales or purchase.


(Mathias Behrle) #2

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.

(albert) #3

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.

(Cédric Krier) #4

The developer as it is defined on RPC.

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.

(Mathias Behrle) #5

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.