-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client does not logout when communication is lost and session expires #553
Comments
This is super useful feedback and is being tracked here so I am closing, but your comments adds a lot more to the discussion so I'm copying it over. |
We're currently observing what looks like a similar issue on our test instance, reopening until we've confirmed whether it is a regression or not. |
I think this is fixed, right? I'll add it to my todo list to see if I can still repo, but if anyone has seen this, please report back here! |
We had one report a while back that we were able to trace to Nina's Qubes laptop which should have been running a reasonably up to date SD Client (we were seeing a long list of API connection attempts on the test instance over the course of several hours, beyond the expected token expiry window). I think it's worth running an isolated test to see if this issue still occurs. |
Unable to repro by following the STR (with one modification where I updated https://github.com/freedomofpress/securedrop/blob/f8aecebfc0836fe1bb4fa633ff83e539cf83a686/securedrop/journalist_app/api.py#L27 to a minute so that I didn't have to wait for 8 hours). What happens in the current client is what we expect: the user is logged out with a new login window that says "Your session expired. Please log in again." If someone can repro this STR, please reopen. |
The client does not automatically logout when it has not been in communication with the server for more than the token duration (8h). The assumption that the Client with continuously refresh with the server.
Steps to reproduce:
This should not happen in normal situations, only if there's an network outage (no communication to the server for 8h)).
In the current format (where the client does not encrypt submission for at-rest-storage) there isn't a very significant impact. However this will pose an issue if #552 is implemented
The text was updated successfully, but these errors were encountered: