Using the extension across a 4 hour window, the passbolt extension keeps logging me out despite me having chosen “Until I log out”. I have kept my browser (Brave) open for this duration, using the extension quite frequently.
I’ve used Passbolt for over two years, first time this has happened, so wanted to bring awareness. I’ve just turned on ‘collect errors’ under the extension settings so I’ll hopefully be able to provide some useful logs.
It’s sounds like you know what to expect so I’m not adding much value in this comment but others might read this in the future and be interested
Sessions are kept alive by the server and we get a few support tickets about session timeouts being too short. I’m not saying your timeout is normal, if your expected session time has changed it could be a bug and logs would be really welcome (thanks!)
Sessions
It’s an aspect of security that the server needs to have sessions kept alive so if a computer goes to sleep, then functionally that’s the same as logging out.
Session Management Timing:
The KeepSessionAliveService runs every 15 minutes (SESSION_CHECK_INTERNAL = 15)
The StartLoopAuthSessionCheckService checks authentication status every 60 seconds (CHECK_IS_AUTHENTICATED_INTERVAL_PERIOD = 60000)
When “Remember until signed out” is selected, the passphrase is stored with timeout = -1 (indefinite)
Laptop Sleep Mode Impact:
When laptops enter sleep mode, the session extension mechanism (KeepSessionAliveService) cannot run
The browser alarms may not fire reliably when the system is in sleep mode
This causes the session to expire even with “Remember until signed out” enabled
Session Validation:
The AuthenticationStatusService makes API calls to /is-authenticated to verify session validity
If the server-side session expires, the extension forces a logout via PostLogoutService.exec()
We have an open task: PB-28142 Session policies
However it requires the browser extension to move from using GPG Authentication to JWT Authentication first and that isn’t going to happen this year.
This is why we currently rely on the server timeout being extended and why it doesn’t persist through long periods where the client isn’t actively keeping the session alive.
I’m actually still waiting on this to happen again to collect the logs - had only occurred a few times across the 6th and 7th. Sounds like your right that something interfered with the timing: I’m on Ubuntu and actually can’t sleep my desktop (until I fix that), so only lock it.
Seems like this is a precise issue to me - have been building a lot of docker images over those days which can be intense, for how I have things setup, on client and server. So during the verification stages, the requests and responses may have timed out - possibly expiring the session?
