wayne zheng (Migrated from SEC-1831) said:
In the Class org.springframework.security.web.savedrequest.HttpSessionRequestCache code: static final String SAVED_REQUEST = "SPRING_SECURITY_SAVED_REQUEST"; and saveRequest/getRequest/removeRequest use the SAVED_REQUEST as session attribute name. it's not a good idea.
thus, it should Like class org.springframework.security.web.context.HttpSessionSecurityContextRepository which has a method named "setSpringSecurityContextKey".
So, the HttpSessionRequestCache class should have a method like setSavedRequestKey(String ...) and allow developer to set the session attribute name.
for example: /user should use /user/login as login entrypoint but /manager should use /manager/login as login entrypoint and must use different springSecurityContextKey, and HttpSessionRequestCache should use different session attribute key.
Comment From: spring-projects-issues
wayne zheng said:
The improved code
Comment From: spring-projects-issues
Luke Taylor said:
Sorry, but I don't really understand why it's not a good idea. Could you please explain why you need to set a different name?
Comment From: spring-projects-issues
Pavel Horal said:
I was just forced to subclass HttpSessionRequestCache because of this. The reason is simple:
I have two different contexts within my servlet - /admin and /web. For each context I have separate filter chain. I am able to separate SecurityContextPersistenceFilter configurations, because HttpSessionSecurityContextRepository allows me to set custom session key. However with HttpSessionRequestCache I am not able to that. Without custom session key the authentication filter from /admin can redirect me to saved request from /web context.
I want filter chains to be completely separated. This is not possible with the current HttpSessionRequestCache. If not anything else, the configuration logic is not consistent with HttpSessionSecurityContextRepository.
Hope the use case is clear (pretty much the same as what is described in the issue description).
Comment From: rwinch
This was fixed via aa5df61eff0f7410bed09b5990c5ed1830d16c60