19.5. Filtering Requests¶

19.5.2.1. Overriding preHandle¶

Here is our initial preHandle method, with a detailed breakdown below.

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

@Override
public boolean preHandle(HttpServletRequest request,
                        HttpServletResponse response,
                        Object handler) throws IOException {

   HttpSession session = request.getSession();
   User user = authenticationController.getUserFromSession(session);

   // The user is logged in
   if (user != null) {
      return true;
   }

   // The user is NOT logged in
   response.sendRedirect("/login");
   return false;
}

The signature of our method must match the definition of preHandle and HandlerInterceptor exactly, even if we don’t need all of the parameters. We will only use the request argument, but we still need to include the response and handler arguments.

Notice that preHandle returns a boolean. The return value will dictate what happens after the handler finishes running. If we return true, then request processing will continue as normal, with the appropriate controller method being called. If we return false, then processing will halt, and no controllers will be called.

Let’s break down this method.

• Line 32: Retrieves the user’s session object, which is contained in the request.
• Line 33: Retrieves the User object corresponding to the given user. Recall that this will be null if the user is not logged in.
• Lines 36-38: The user object is non-null, so the user is logged in. Allow the request to be handled as normal.
• Lines 41-42: The user object is null, so we redirect the user to the login page.

This method has the effect of preventing access to every page on the app if a user is not logged in. This creates one not-so-minor problem: How will a user access the login page if they are not logged in?

19.5.2.2. Creating a Whitelist¶

The term whitelist often refers to a list of items that are NOT subject to a given restriction. For our filter to fully work, we need a whitelist of pages that may be accessed by any user, regardless of whether or not they are logged in.

Let’s define our whitelist above preHandle:

27

private static final List<String> whitelist = Arrays.asList("/login", "/register", "/logout", "/css");

At minimum, users should be able to access the routes associated with logging in and out. Depending on the desired use-cases for your application, you may want to add additional pages to the whitelist. For example, many web apps have a home page that does not require being logged in to view.

We now need a way to check whether or not a given request is whitelisted. The following utility method does the trick:

29
30
31
32
33
34
35
36

private static boolean isWhitelisted(String path) {
   for (String pathRoot : whitelist) {
      if (path.startsWith(pathRoot)) {
            return true;
      }
   }
   return false;
}

This method takes a string representing a URL path and checks to see if it starts with any of the entries in whitelist. If you wanted to be more restrictive, you could use .equals() instead of .startsWith(). If the path is whitelisted, we return true. Otherwise, we return false.

We can now check all requests against the whitelist within preHandle:

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

@Override
public boolean preHandle(HttpServletRequest request,
                        HttpServletResponse response,
                        Object handler) throws IOException {

   // Don't require sign-in for whitelisted pages
   if (isWhitelisted(request.getRequestURI())) {
      // returning true indicates that the request may proceed
      return true;
   }

   HttpSession session = request.getSession();
   User user = authenticationController.getUserFromSession(session);

   // The user is logged in
   if (user != null) {
      return true;
   }

   // The user is NOT logged in
   response.sendRedirect("/login");
   return false;
}

request.getRequestURI() returns the request path (see the docs for more details). Lines 43-47 check the path against the whitelist, returning true (that is, allowing the request to proceed) if the path is whitelisted.

With our filter complete, we simply need to let Spring know about it to complete our authentication code.