#filterprocessurl

Over the last week I've been working to get Spring Security 3.0.7 integrated into a Web application I'm developing. One of the first things I did was set the URL for the login form page to /login. It's easy to do by setting the loginFormUrl on the LoginUrlAuthenticationEntryPoint if you're not using the namespace (namespace equivalent is the login-page attribute of the <form-login> tag).

The problem is that the URL that your login form POSTs to has to be different. The reason is, behind the scenes, the UsernamePasswordAuthenticationFilter handles the request. Even when you set the postOnly attribute to true, an exception is thrown (as if you had POSTed from a form) when you try to access the page with a simple GET.

Fortunately, the fix is fairly trivial. We simply must override the requiresAuthentication() method in the UsernamePasswordAuthenticationFilter class.

Overriding requiresAuthentication()

When a request is handed off to the UsernamePasswordAuthenticationFilter, the doFilter() method calls the requiresAuthentication() method to determine whether or not it needs to handle the request or if it needs to forward the request to the next guy in the filter chain. We are going to override the method to check which HTTP method was used to access the page; if it's GET, then we can safely ignore the request and let the next filter handle it.

Here is an example of overriding the method:

public class MyAuthenticationFilter extends UsernamePasswordAuthenticationFilter { @Override protected boolean requiresAuthentication(HttpServletRequest request, HttpServletResponse response) { if(request.getMethod().equals("POST")) { return super.requiresAuthentication(request, response); } else { return false; } } }

As you can tell, it's not doing a whole lot here. All our overriding method does is check the HTTP method type. If it's a POST, we yield to the UsernamePasswordAuthenticationFilter's logic to apply its rules (and probably handle the request). If it's anything other than a POST, such as GET, we return false. This will signal to the UsernamePasswordAuthenticationFilter's doFilter() method that it does not need to handle the request. It gets sent to the next guy in the filter chain and our login form will get called.

This way, we can have our custom login form located at, say, /login and yet we can still POST to /login to have the UsernamePasswordAuthenticationFilter invoked and the user authenticated.