Best Way of Ending User Sessions When 'Remember Me' is Ticked On. #4977

New Issue

OVERLORD · 2026-02-05T09:30:37+03:00

OVERLORD commented

2026-02-05 09:30:37 +03:00

Originally created by @RyanH264 on GitHub (Oct 1, 2024).

Attempted Debugging

I have read the debugging page

Searched GitHub Issues

I have searched GitHub for the issue.

Describe the Scenario

Hi Bookstack community.

I have a bookstack application that contains some sensitive data. A number of my users have checked the "remember me" checkbox to keep themselves logged in for longer. I noticed that one of my users had been logged in for over a month and I wanted to find out what the best option would be to limit the user so that the most amount of time they can be logged in is 8 hours. This is in an attempt to ensure that if the users device becomes compromised by a bad actor, that they don't have access to the bookstack data for very long.

I'm happy to remove the checkbox from the blade file so that my users can't tick it, but I wanted to see if there were any better / suggested ways of handling this instead. I'm guessing I could also setup a script to run every 8 hours that clears the files (excluding the .gitignore file) in the sessions folder as well.

Exact BookStack Version

24.02.3

Log Content

No log for this issue as not really a bug and more so a lack of knowledge on my behalf.

Hosting Environment

Microsoft Windows Server 2022 Datacenter / AWS EC2 running xampp, apache & mySQL.

Originally created by @RyanH264 on GitHub (Oct 1, 2024). ### Attempted Debugging - [X] I have read the debugging page ### Searched GitHub Issues - [X] I have searched GitHub for the issue. ### Describe the Scenario Hi Bookstack community. I have a bookstack application that contains some sensitive data. A number of my users have checked the "remember me" checkbox to keep themselves logged in for longer. I noticed that one of my users had been logged in for over a month and I wanted to find out what the best option would be to limit the user so that the most amount of time they can be logged in is 8 hours. This is in an attempt to ensure that if the users device becomes compromised by a bad actor, that they don't have access to the bookstack data for very long. I'm happy to remove the checkbox from the blade file so that my users can't tick it, but I wanted to see if there were any better / suggested ways of handling this instead. I'm guessing I could also setup a script to run every 8 hours that clears the files (excluding the .gitignore file) in the sessions folder as well. ### Exact BookStack Version 24.02.3 ### Log Content No log for this issue as not really a bug and more so a lack of knowledge on my behalf. ### Hosting Environment Microsoft Windows Server 2022 Datacenter / AWS EC2 running xampp, apache & mySQL.

OVERLORD added the 🐕 Support label 2026-02-05 09:30:37 +03:00

OVERLORD closed this issue

2026-02-05 09:30:38 +03:00

OVERLORD commented

2026-02-05 09:30:40 +03:00

@ssddanbrown commented on GitHub (Oct 1, 2024):

Hi @RyanH264,

I'm guessing I could also setup a script to run every 8 hours that clears the files (excluding the .gitignore file) in the sessions folder as well.

No, I don't think that would do it, The "remember me" option works around sessions by storing a token in the database (table: users -> column: remember_token) which is then matched against user cookie that's placed on login with "remember me" checked.
You could automate/script updates to the users column to set that to null where not already null, to wipe out remember tokens. In this case the login will expire with the session.

As a cheeky smart alternative, you could create some triggers in the database to auto-set this to null on any creation/update:

CREATE TRIGGER clear_remember_token_ins BEFORE INSERT ON users FOR EACH ROW SET NEW.remember_token = null;
CREATE TRIGGER clear_remember_token_upd BEFORE UPDATE ON users FOR EACH ROW SET NEW.remember_token = null;

Backup the DB before playing around with things, and test the process works for your scenarios as things could differ!

so that the most amount of time they can be logged in is 8 hours.

Note that the existing SESSION_LIFETIME option does not cap the login time like that, it's how long they expire after no activity. If the user performs activity (page load, form submit etc...), the time window restarts for another SESSION_LIFETIME amount of minutes again.

@ssddanbrown commented on GitHub (Oct 1, 2024): Hi @RyanH264, > I'm guessing I could also setup a script to run every 8 hours that clears the files (excluding the .gitignore file) in the sessions folder as well. No, I don't think that would do it, The "remember me" option works around sessions by storing a token in the database (`table: users -> column: remember_token`) which is then matched against user cookie that's placed on login with "remember me" checked. You could automate/script updates to the users column to set that to null where not already null, to wipe out remember tokens. In this case the login will expire with the session. As a cheeky smart alternative, you could create some triggers in the database to auto-set this to null on any creation/update: ```sql CREATE TRIGGER clear_remember_token_ins BEFORE INSERT ON users FOR EACH ROW SET NEW.remember_token = null; CREATE TRIGGER clear_remember_token_upd BEFORE UPDATE ON users FOR EACH ROW SET NEW.remember_token = null; ``` _**Backup the DB before playing around with things, and test the process works for your scenarios as things could differ!**_ --- > so that the most amount of time they can be logged in is 8 hours. Note that the existing `SESSION_LIFETIME` option does not cap the login time like that, it's how long they expire after no activity. If the user performs activity (page load, form submit etc...), the time window restarts for another `SESSION_LIFETIME` amount of minutes again.

OVERLORD commented

2026-02-05 09:30:44 +03:00

@RyanH264 commented on GitHub (Oct 1, 2024):

Thanks Dan!

Triggers sound like the way to go. I'll be sure to fill in my change management forms, schedule the update outside of peak times, perform my backups and update this thread once the change has been implemented into prod so that anyone else looking for this functionality can see how my implementation went.

@RyanH264 commented on GitHub (Oct 1, 2024): Thanks Dan! Triggers sound like the way to go. I'll be sure to fill in my change management forms, schedule the update outside of peak times, perform my backups and update this thread once the change has been implemented into prod so that anyone else looking for this functionality can see how my implementation went.

OVERLORD commented

2026-02-05 09:30:45 +03:00

@RyanH264 commented on GitHub (Oct 9, 2024):

Update:

I have performed the following in my staging / test environment:

Created users with a remember token.
Backup of mySQL database.
Creation of triggers.

After this, I logged into Bookstack with the users that had a remember token and checked the database again using:
"SELECT id, email, remember_token FROM users WHERE remember_token IS NOT NULL;"
And I can confirm that the remember token was cleared.

I will update into my prod environment later and provide a further update but all appears to be working.

@RyanH264 commented on GitHub (Oct 9, 2024): Update: I have performed the following in my staging / test environment: 1. Created users with a remember token. 2. Backup of mySQL database. 3. Creation of triggers. After this, I logged into Bookstack with the users that had a remember token and checked the database again using: "SELECT id, email, remember_token FROM users WHERE remember_token IS NOT NULL;" And I can confirm that the remember token was cleared. I will update into my prod environment later and provide a further update but all appears to be working.

OVERLORD commented

2026-02-05 09:30:47 +03:00

@RyanH264 commented on GitHub (Oct 9, 2024):

Final Update:

I have performed the same steps in prod and everything is working as intended.

Thanks again to Dan and hopefully anyone else with this problem can follow the same steps to achieve a good outcome.

@RyanH264 commented on GitHub (Oct 9, 2024): Final Update: I have performed the same steps in prod and everything is working as intended. Thanks again to Dan and hopefully anyone else with this problem can follow the same steps to achieve a good outcome.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#4977