Include FilterChain on SessionInformationExpiredEvent to allow continuing the request

[arvyy]

I expect to always be able to invoke endpoints marked with permitAll. However, ConcurrentSessionFilter early aborts such requests at the edge of expiration.

spring-security/web/src/main/java/org/springframework/security/web/session/ConcurrentSessionFilter.java

Line 145 in ed6ff67

return;

and there doesn't seem a way to sidestep this early return through SessionInformationExpiredStrategy because it doesn't expose FilterChain to call doFilter on.

[marcusdacoregio]

Hi, @arvyy, thanks for the report.

permitAll means that it will allow requests with/without authentication to go through, but Spring Security filters will continue doing what they do. Therefore, since you have concurrent session control, if you perform a request with a session that has expired by concurrency, the ConcurrentSessionFilter won't allow that request to go through.

Can you elaborate more on your use case? How does the session expire? What are those requests that you always want to go through?

[arvyy]

I have a /currentUser endpoint that I want to work regardless if user is logged in or not (in latter case it'd return null). On frontend I create a timer until the end of the session (which I know from an auxiliary cookie). At the end of the timer, I call /currentUser, and if it weren't null (because user was browsing in different tab), I restart the timer. If it was null, I know user has been idle too long and change frontend view to the login screen. This is currently broken, because frontend instead of receiving a json response of an expected form, it instead receives a plain text message "This session has been expired ...".

I understand that permitAll still invokes security filters, and that's desired, because I still want to be able to fetch (just potentially empty) security context's user authentication value. My problem isn't with design as a whole, but with inflexibility of ConcurrentSessionFilter specifically.

[marcusdacoregio]

It seems to me that your /currentUser endpoint should require authentication and instead of returning null when the user is not authenticated, it should return a 401. This way you can provide a SessionInformationExpiredStrategy implementation that returns 401 and your frontend code can be adapted to expect it.

But, if you do not want to do that and instead return null, you can provide a SessionInformationExpiredStrategy implementation that writes nothing to the response. Does that make sense?

[arvyy]

Doesn't seem like a robust solution. SessionInformationExpiredStrategy shouldn't be tight coupled to specific endpoint's concerns, especially since there can be more than one permitAll endpoint in an application (albeit the one I shared is the one most likely to trigger this issue). As a current workaround I'll probably reimplement the concurrent session filter altogether.