feat: introduce a filter to refresh camunda authentication #36718
Conversation
2c3e4b5 to
3f14e6a
Compare
4b73713 to
2e71a01
Compare
3454292 to
4861e56
Compare
|
@maryarm please check CI error reasons before re-enqueing PRs into the merge queue! (via the I see compilation errors for this PR in the merge: https://github.com/camunda/camunda/actions/runs/17033591357/job/48281074149 This can happen if there are newer changes on |
2eaa31e to
09b9e5f
Compare
| try { | ||
| handleAuthenticationRefresh(request); | ||
| } catch (final Exception e) { | ||
| logger.debug("The session can't be refreshed."); |
There was a problem hiding this comment.
🔧 Late to the party, but can we also make sure to add the exception as the last argument, so we can also see the error potentially causing this for debugging?
|
|
||
| private static void initializeRefreshAttributes(final HttpSession session, final Instant now) { | ||
| session.setAttribute(LAST_REFRESH_ATTR, now); | ||
| session.setAttribute(LAST_REFRESH_ATTR + "_LOCK", new Object()); |
There was a problem hiding this comment.
❓ Cool, how does this work with the session storage? I'm 0% familiar with session storage in Spring - is it loaded once in-memory and reused, or is it possible that two threads load the session from the persistent store, and we get 2 different object references here?
| } | ||
|
|
||
| @Test | ||
| void shouldOnlyRefreshOnceWhenMultipleConcurrentRequests() throws Exception { |
There was a problem hiding this comment.
💭 Does this actually do what we think? There is no guarantee we're actually testing the case where two requests are trying to refresh at the same time, is there? Am I missing something? I don't get how we're testing the refresh is truly synchronized 🤔
Description
When a user logs in, we determine their associations once (membership in roles, groups, tenants; application authorizations) and put them into the web session.
When these associations change (e.g. user is removed from a group; authorizations change), then this is not reflected in this cached state. Accordingly, as long as the user's session is alive, the changes do not take effect for them.
Related issues
closes #34698