Sandro Ruch (Migrated from SEC-1542) said:
Currently the AbstractRememberMeServices contains a private variable userDetailsChecker which is initialized with the AccountStatusUserDetailsChecker but there is no way to overwrite this like in the AbstractUserDetailsAuthenticationProvider class (variable preAuthenticationChecks). In addition the two default implementation are not the same.
1: make userDetailsChecker configurable in AbstractRememberMeServices
2: implement the DefaultPreAuthenticationChecks not as private class like the AccountStatusUserDetailsChecker
Luke Taylor said:
I can certainly add a setter method to AbstractRememberMeServices.
The private classes in AbstractUserDetailsAuthenticationProvider are really an implementation detail for that class, which are directly tied to it. The point is that the messages which are displayed to a user should be tailored depending on whether they have successfully entered their credentials or not. That doesn't apply in a context like remember-me where the token is either accepted as part of a request or rejected outright.
Sandro Ruch said:
That would be great... also in case of SimpleUrlAuthenticationFailureHandler... we need just to manipulate the defaultFailureUrl (attache a parameter in some case)... if there where a method like in the class LoginUrlAuthenticationEntryPoint (determineUrlToUseForThisRequest) we would be able to just extend from SimpleUrlAuthenticationFailureHandler and overwrite the designated method (getting the defaultFailureUrl). For now we had to copy the whole code (from SimpleUrlAuthenticationFailureHandler and ExceptionMappingAuthenticationFailureHandler) into a new one... not much but also not so nice...
Added the setter method.