Most modern web applications and cloud services that are frequently re-visited by users provide some sort of “Stay Logged In” feature (think Office 365 or GMail) whereby a user accessing the service from the same device and browser is not forced to re-enter their credentials each and every time they access it. With Mendix we have found this common capability to be completely absent which has caused no small amount of complaints from our user base.
While the Mendix runtime does provide a PersistentSessions setting that persists session data in the database and expires them based on a defined SessionTimeout value, this is not carried through in any meaningful way to the users browser experience. Session cookies created in the users browser are not set with an expiration value and do not persist locally after the browser is closed, therefore closing the browser removes the temporary session cookies and the user is forced to login again.
Similarly, if a user does not close their browser but rather minimizes it only to return after the SessionTimeout period has expired, they are forced to login again.
Provide configuration options that allow PersistentLogins and a LoginTimeout value to be defined. When enabled, user logins will persist in-between closing and re-opening the same browser as well as in-between normal SessionTimeout intervals. This could be implemented by setting a secure client cookie that has an expiration datetime and having an encrypted token as it’s value. These tokens can be saved on the server and associated to the user account similar to sessions. Also similar to sessions, these login tokens would eventually expire, the difference being they may have a much longer expiration timeout than a typical session (e.g. 14 days instead of 30 minutes).
If a request cannot be initially associated with an authenticated session, then check for the existence of the encrypted token on the client. If it exists, validate it against the tokens in the database, which are themselves associated with a particular user. If the token exists and is still valid, authenticate the user into a normal session without forcing them to re-enter their credentials. If not, make them re-authenticate.