Auto sign-out

[johnnyjoygh]

Discussed in https://github.com/orgs/usememos/discussions/4075

^{Originally posted by rathmannm October 31, 2024} Hi,

I'm storing sensitive contents in Memos so it would be nice to have an auto sign-out feature where you can specify after how many minutes you get signed out automatically.

[JodhwaniMadhur]

can someone tell me about the DB structure and a bit of the API documentation?

my plan to implement this is to store the last-login-time and log-out-after data in the db and check if the curr-time subracted from the last-login time is greater than the log-out-after time and log out the user based on that.

we can add the UI for setting the "log out after time" in the preferences page.

[johnnyjoygh]

@JodhwaniMadhur I think the point of this issue is to make the access token duration configurable, which is now 1 week by default. https://github.com/usememos/memos/blob/main/server/router/api/v1/auth.go#L18

[JodhwaniMadhur]

oh ok, thanks for the guidance, will make the feature work this way.

[RoccoSmit]

To add to @johnnyjoygh 's comment. I believe there are 2 places to take into consideration. At registration the expiry is set to 7 days in the future, subsequent logins set the expiry 1 year in the future.

[RoccoSmit]

I found the reference to the two locations https://github.com/usememos/memos/issues/4009#issuecomment-2412696560

[RoccoSmit]

@JodhwaniMadhur, out of interest, how are you intending to capture a large range of expiry possibilities? Current expiry is in days (multiplied for years), OP seems like they need expiry in minutes

[JodhwaniMadhur]

I was thinking along the lines of store the time in db and check if every time they access the site that it is valid or not and log them out based on that, and every time the user logs in/ does access the site, we reset it for the time they set in preferences and have a 1-60 mins timer option for auto log out.

same could be done for access token, like refresh it every time the person logs in and log them out if it isn't valid.

However, I need to deep dive in the code to see if I can fit it in properly or not.

[JodhwaniMadhur]

ok, i saw the code and i don't think we pass the acess token to the frontend, do we? there is no way to edit it's attributes or the expireAt setting in the frontend, isn't it? I feel we need to create a userStore.updateUserSetting for access token and then set the expiration time through it.

Also, will need to create an API for the same to update this in the database frequently.

Also, I will need some help with the proto file to create the API for this.

Does this sound good?

[RoccoSmit]

The access token is passed to the FE on signin and is stored in a cookie. Creating new tokens are done on the BE in auth_service.go. There are many moving parts if you are going to go down the path of modifying access tokens.

I believe there is a simpler way using the existing mechanisms of Memos to achieve OPs goal. The idea is:

1. The addition of a user setting to determine how long (in min) a user wants to wait before auto signout. Default = 0 and this will leave the current behavior as is and if changed will sign user out after minutes set.

2. Adding a user activity tracker on the FE e.g. track the date/time the last mouse click / key press was actioned

3. Periodically check if last action + auto signout minutes are < current date/time and if it is then use the already built signOut feature to sign the user out

[JodhwaniMadhur]

THANKS for the response first of all.

my concern is wouldn't this be client heavy and not so reliable with only frontend.

I am not sure of the scenario where in say auto_signout_mins have passed but due to SSO, cookies, user is still able to login.

Plus wouldn't this be client heavy and be easily cheated with? But again this is a tradeoff situation.

I am pro-DB, like have another column in the user table which has session-timeout and we read from it on every access and decide whether to let the user go in or not.

I certainly understand that DB reads and writes are expensive but again, as I said, it is a tradeoff between security and time.

[RoccoSmit]

The reasons I suggested tracking changes on the FE were:

1. Features call the API multiple times to get all required data, e.g. the memolist API endpoint is called 2 times for the home page (once for the memos and once for the metadata) and each image on the page is a API call. If the db is updated for each call it feels like excessive updating.

2. Not waiting for API requests would avoid scenarios where a user types a memo for longer than their timeout, saving and getting logged out in the process. As well as people being able to read the content on the screen until someone clicks a link.

3. It would cause 3rd party applications to be unaffected.

Adding the FE and db storage options together could look as follows:

1. Add a timeout user setting

2. When signing in use the timeout setting to set the auth token expiry

3. FE periodically checks in to say the users is still active on the site. Server creates a auth token with new expiry date, deletes old auth token (will need to make sure no other calls are using this token before deleting). FE adds new auth token to cookies

4. FE periodically checks if auth token expiry is in past and logs out if it is

Some endpoints that would be helpful for this approach

[JodhwaniMadhur]

not the auth token but my original approach of saving just the number_of_mins as a field in the db, periodically check for activity and if not done till x mins. then log out. no need to hamper the access token in any scenario

[JodhwaniMadhur]

any updates on what solution I should proceed with?