Session timeout in UI should be adjusted
Description
CSP Request Details
CSP Rejection Details
Potential Workaround
Attachments
Checklist
hideActivity
Yury Barsukou January 20, 2025 at 10:08 AM
Tested on snapshot, works fine. Video added
Craig McNally January 7, 2025 at 9:35 PM
I forget if we were using tags or not… if we were please create a tag so we can easily find the appropriate commit hash for resolutions. If not, that’s fine.
Craig McNally January 7, 2025 at 9:34 PM
Thanks for the reminder. In that case I think it’s fine to test this in a Q env and if it looks good there, close this as done. Please work with FSE to identify an env. which can be used for this (rebuild UI), misconfigure RTR, verify, fix RTR configuration.
Zak Burke January 6, 2025 at 1:38 PM
, there will not be a release corresponding to this ticket because this was a Q-specific/Eureka-specific fix and in Q we still use commit-hashes, not actual releases, for Eureka work in the UI.
Craig McNally January 2, 2025 at 3:18 PM
I will fix this typo in a PR to stripes-core#keycloak-quesnelia (caused by PR #1511). We'll want to include it a Q CSP.
it looks like QCSP8 was slated to go GA on Dec. 30. I don’t think that happened. If that’s accurate, we could try to get this into QCSP8. However, based on you summary (thank you for that BTW), this shouldn’t be an issue if RTR is configured correctly, which suggests to me that this isn’t critical. I see the PR has already been merged to the Q branch, but I don’t see a release yet. I personally think the play here is to include this into QCSP9 (if there is one), but it’s probably not worth forcing a QCSP9 just for this.
The customer got back to us with the following question: they have a timer at the top of the page, and when the login timeout is over, nothing happens, and the user remains logged in. We are wondering what’s the best way for us to adjust the session timeout accordingly