Session expiry does not redirect to login
Expected behavior
An expired session leads to the user having to log in again
Actual behavior
The mail app seems to be broken but does not force a new login.
Reproduce this by opening two tabs - one with the dashboar or similar and one with the mail app. Log out in the dashboard tab, and try to open any message on the mail tab. The page will be blank but no redirect will be triggered.
Mail app
Mail app version: master
Server configuration
Operating system: Ubuntu 22
Web server: Apache
Database: MySQL
PHP version: 8.0
Nextcloud Version: NC 23 beta 3
I reproduced the issue but the root of the problem could be deeper than it looks because the same behaviour is found in Deck and Passman.
Thanks for taking a look, that's good to know!
Talk: https://github.com/nextcloud/spreed/blob/master/src/store/talkHashStore.js#L100
I'm wondering if we should ignore very short maintenance outages. E.g. when an admin updates an app while a user has the app open. This could make one or a few requests fail. Especially when they are not essential (e.g. background synchronization or loading an avatar) asking the user to reload is too much.
I'm wondering if we should ignore very short maintenance outages. E.g. when an admin updates an app while a user has the app open. This could make one or a few requests fail. Especially when they are not essential (e.g. background synchronization or loading an avatar) asking the user to reload is too much.
Ok, it is actually there. https://github.com/nextcloud/server/blob/48ece9f345eac0d889c10ceacd48a5cf3999f4cf/core/src/OC/xhr-error.js#L55
if (_.contains([302, 303, 307, 401], xhr.status) && OC.currentUser) {
maintenance outage would be 503 Service Unavailable
But that doesn't have an effect on this app.
We need to clarify what this ticket is about.
The goal is not to have a brute force reload, the goal is to handle this as graceful as possible. Any short term hiccup should not even be noticeable to the user.
E.g. short maintenance outage because an app is updated -> retry requests until they pass, after x attempts/time go to the maintenance page. But make sure no user data is lost. In case of expired sessions we can guide the user to a login right away. Yet, if possible, no data should be lost. Server downtime (connection timeouts) can be handled like maintenance down times.
Catching any 503 sounds a bit dangerous to me. I've opened https://github.com/nextcloud/server/pull/33173 to make the Nextcloud maintenance distinguishable from other 503s.
I'm looking into making Nextcloud error responses a bit more semantic, e.g. real 404s for resources that are not found: https://github.com/nextcloud/server/pull/33175.
~~I would also like to look into 401s for required authentication. Right now requests are redirected to the default page instead.~~
Nextcloud returns
{"message":"Current user is not logged in"}
For an unauthenticated request to /apps/mail already. So this should be detectable right now.
Blocked by https://github.com/nextcloud/server/pull/33173
the goal is to handle this as graceful as possible
- Keep retrying to overcome short maintenance downtimes: https://github.com/nextcloud/nextcloud-axios/pull/510
- Fetch new CSRF token if it expires: https://github.com/nextcloud/nextcloud-axios/pull/511
As a third I would add also some kind of polling for the expired session, so that the app reconnects if another tab logs in. We could wait something like 3m for this, otherwise fail hard and do the dreaded reload.
Looks like the third condition is even caught already. If I open Mail, wait for everything to load, restart the webserver to kill the session and trigger a mailbox refresh, the request fails with 412, is retried thanks to https://github.com/nextcloud/nextcloud-axios/pull/511 and then succeeds.
The final piece can be found at https://github.com/nextcloud/mail/pull/7515.