So that we can implement other ways of serialising the request to the cookie value
Comment From: sjohnr
@bhuism thanks for the suggestion. For clarity, can you describe your use case for adjusting the behavior of this class?
Also, I think the preference generally would be to provide customization hooks, such as a Function<String, String> cookieEncoder, etc. instead of encouraging/allowing inheritance-based overrides. While this class (CookieRequestCache) is not final, I think enhancements would ideally treat it as such.
Note that it's usually best to discuss an issue prior to opening a PR.
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: bhuism
@sjohnr Morning, I will discuss it first next time. Idea in this case that the cookie value can be crypted, so that it can not be changed by a client.
Customisation hook via function is perfectly fine offcource, why is this preferred btw?
Comment From: sjohnr
@bhuism, thanks for the reply! Customization hooks are preferred because they encourage composition and delegation instead of inheritance. You can then build up bigger and more complex implementations by combining one or more existing implementations together with your own logic.
Comment From: rwinch
Spring Security allows customization of how the SecurityContext is persisted via SecurityContextRepository implementations, CSRF token via CsrfTokenRepository, etc. There are already hooks for how everything in Spring Security is persisted. If you find something specific that you cannot customize, please let us know and we will work with you on how to do it or adding something that you can do it.