Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1058: Refactor AbstractProcessingFilter to make use of new authentication success and failure strategies #1309

spring-issuemaster opened this Issue Dec 12, 2008 · 2 comments


None yet
1 participant

Migrated from SEC-1058

Luke Taylor said:

I’ve committed some substantial refactorings for this issue.

AbstractProcessingFilter now has an AuthenticationSuccessHandler and AuthenticationFailureHandler injected, which perform all the functionality of the previous navigational behaviour on authentication success and failure. (See parent issue for more information on the implementations).
If no implementations are injected, the defaults are a SavedRequestAwareASH (which has the defaultTargetUrl=“/”) and a SimpleUrlAFH with no URL set (which will send a 401 (unauthorized) error by default with the reported exception message).

Thus the following properties are no longer present in this class:

defaultTargetUrl and alwaysUseDefaultTargetUrl

and the corresponding strategy properties should be used instead. “serverSideRedirect is” now called “useForward” on the SimpleUrlAuthenticationFailureHandler.

The methods related to determining Urls for success and failure have also been removed, as has the TargetUrlResolver.

I also removed the additional “hook” methods to simplify things – onPreAuthentication was redundant as attempAuthentication has to be implemented by subclasses anyway and it was called immediately before this method. The onSuccessfulAuthenticaition and onUnsuccessfulAuthentication methods are superseded by the use of the strategy objects. In any case, successfulAuthentication() and unsuccessfulAuthentication() are already protected and can thus also be overridden.

During the refactoring, it became obvious that the OpenID filter was making use of these methods in a rather contrived manner to get round the fact that the base class doesn’t cater for situations where there is more than one stage to the authentication process. It was throwing an exception from the attemptAuthentication method to indicate that a redirect to the service provider should be performed from the authenticationFailure method (since this had access to the response object). Therefore, I’ve modified attemptAuthentication() to now takes a response object in addition to the request (to allow subclasses to perform a redirect). It can return null to indicate that the authentication process is still continuing.

The OpenIDAuthenticationProcessingFilter now makes use of this ability, performing the redirect to the OpenID service provider from the attemptAuthentication() method (returning null) and then handling the redirect back from the service in the same method.

Luke Taylor said:

I’ve also refactored AbstractProcessingFilter to remove the use of the getDefaultTargetUrl template method in favour of a constructor argument instead (since the method was effectively called from the constructor and nowhere else).

@spring-issuemaster spring-issuemaster added this to the 3.0.0 M1 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment