Content
View differences
Updated by Jan Sandbrink about 1 year ago
### Steps to reproduce
1. Set a session timeout of 5 minutes in [admin settings](https://openproject.local/admin/settings/authentication)
2. Go to a work package page and open the activity tab (/projects/:slug/work\_packages/:id/activity)
3. Suspend your computer (e.g. close laptop lid) for at least 5 minutes
4. Resume computer and open the tab, wait a bit
### What is the buggy behavior?
The browser shows a pop-up to enter username and password (not an OpenProject login form, a browser pop-up).
### What is the expected behavior?
Weak expectations. Any of:
* Redirecting user to login form (careful: is data-loss possible this way?)
* Showing an error message that meeting can't be polled in the background
* no UI feedback
### Technical notes (Root Cause)
The cause of this seems to be, that the frontend code polling `/work_packages/:id/activities/update_streams` does not include the `X-Authentication-Scheme: Session` header. Most other frontend requests we do, include this header. It is used to guide the server's response in the `WWW-Authenticate` header, which the user interprets to decide whether a login form should be shown or not.
The root cause might be the same as for #64088.
### Screenshots
Similar to this one (but with a different page in the background):
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/605017/content">
1. Set a session timeout of 5 minutes in [admin settings](https://openproject.local/admin/settings/authentication)
2. Go to a work package page and open the activity tab (/projects/:slug/work\_packages/:id/activity)
3. Suspend your computer (e.g. close laptop lid) for at least 5 minutes
4. Resume computer and open the tab, wait a bit
### What is the buggy behavior?
The browser shows a pop-up to enter username and password (not an OpenProject login form, a browser pop-up).
### What is the expected behavior?
Weak expectations. Any of:
* Redirecting user to login form (careful: is data-loss possible this way?)
* Showing an error message that meeting can't be polled in the background
* no UI feedback
### Technical notes (Root Cause)
The cause of this seems to be, that the frontend code polling `/work_packages/:id/activities/update_streams` does not include the `X-Authentication-Scheme: Session` header. Most other frontend requests we do, include this header. It is used to guide the server's response in the `WWW-Authenticate` header, which the user interprets to decide whether a login form should be shown or not.
The root cause might be the same as for #64088.
### Screenshots
Similar to this one (but with a different page in the background):
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/605017/content">