As I said in a Stack Overflow question that I posted yesterday, Spring SessionRepositoryFilter is not applied to forwarded requests.
When there's an error, then the request is forwarded to /error, with a dispatch type of ERROR, but SessionRepositoryFilter is only applied to requests with dispatch type REQUEST. That means that a new session ID is created by tomcat, and the client uses this on subsequent requests, which are then rejected as unauthorized by the session repository.
AbstractFilterRegistrationBean#determineDispatcherTypes sets all dispatch types for filters that extend org.springframework.web.filter.OncePerRequestFilter in spring-web, but SessionRepositoryFilter extends org.springframework.session.web.http.OncePerRequestFilter in spring-session-core.
This change sets all dispatch types for filters extending either OncePerRequestFilter class.
Comment From: quaff
It's very risky to change the behavior of org.springframework.web.filter.OncePerRequestFilter.
Comment From: wilkinsona
It's very risky to change the behavior of org.springframework.web.filter.OncePerRequestFilter.
Unless I have missed something, this PR doesn't do that. Instead, it's treating org.springframework.session.web.http.OncePerRequestFilter in the same way as we already treat org.springframework.web.filter.OncePerRequestFilter.
That said, I'm still not sure that this is something that we should do. I would prefer that it's fixed in Spring Session by it using org.springframework.web.filter.OncePerRequestFilter instead of org.springframework.session.web.http.OncePerRequestFilter, although we may still need to do something in the meantime. I've raised this with the Spring Session team and we're waiting to hear back from them.
Comment From: wilkinsona
Chatting with @marcusdacoregio, I was reminded that we have spring.session.servlet.filter-dispatcher-types to control the session filter's dispatcher types. It defaults to async, error, and request so determineDispatcherTypes on the filter registration bean should not be involved.
Judging by the problem description above, it sounds like that may not be working as intended. @fisco-unimatic thanks for the proposal here, but I don't think it's the right way to fix the problem that you seem to be having. Can you please open an issue with a minimal sample that reproduces it so that we can investigate?
Comment From: fisco-unimatic
ok - I'll try to put together an example and then raise an issue
Comment From: fisco-unimatic
In case any ends up here looking for a solution to a similar problem, it turns out that our application was excluding SessionAutoConfiguration. If I remove that exclusion, then it imports SessionRepositoryFilterConfiguration, which sets the dispatch types.
If for some reason you wanted to exclude SessionAutoConfiguration, you could instead make your session configuration class extend AbstractHttpSessionApplicationInitializer. That would also set the dispatch types for you.