mardi août 02, 2005

Authorization servlet filter for JSF
(Craig McClanahan should be given all credit for the following content)

There's a behavior in JavaServer Faces (JSF) technology that can feel a little awkward - the URL shown in the navigator is one page late compared to what is actually showing in the browser. This is by design and, from 30,000 feet, the result of using RequestDispatcher.forward() in the controler. Unless you work for Sun and really want to show implementation details like the /faces context in the URL (JSF rules!), I would suggest hiding the URL altogether.

The other side effect is that it can be tricky to obtain the destination page (vs. the source) page to implement a role filter using servlet filters. Servlet filters are elegant here because they are orthogonal to the application and not linked to JSF APIs. They can implement authentication (is the person logged in?) and authorization (can the person access this required target page?). Although a J2EE 1.3 API specification level (JSP 1.2, Servlet 2.3) should be enough for JSF 1.1, you will need to upgrade to a J2EE 1.4 runtime in order to use new Servlet 2.4 features. This is required to get the destination page to implement the authorization piece of the filtering. So a filter would look like this:

public void doFilter(....) throws ... {
    String RESTRICTED_PAGE = "/ManagerPage.jsp";
    try {
        // getting the *destintation* page
        String relativePath = request.getServletPath() + request.getPathInfo();

        // Trying to access a restricted page
        if ( RESTRICTED_PAGE.equals(relativePath) ) {
            // implement authorization
            ....
            if ( !authorized  ) {
                // not authorized
                resp.sendRedirect("/faces/error.jsp");
            }
        }
        chain.doFilter(request, response);
    }
}

The web.xml deployment descriptor should also be updated to J2EE 1.4 :

<web-app      version="2.4"
                xmlns="http://java.sun.com/xml/ns/j2ee"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
                       http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

and have the following filter mapping :

<filter-mapping>
    <filter-name>Role Filter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
</filter-mapping>

If you can't use a J2EE 1.4 runtime (again, only required by the filter, not by the JSF application per se), the alternate strategy would be to "defensively" code the authorization logic in each managed-bean page constructor. In that case you could avoid code replication by having an indirection call from each page constructor to a session- or application-scope managed bean with the logic, but you're still responsible for calling this authorization method and the filter still sounds like a better approach.

All this information is applicable and has been tested on Java Studio Creator which by default uses Sun Application Server 8 (a free J2EE 1.4 implementation). An article on Sun Developer Network on this "feature" and focusing on Sun Java Studio Creator should be made available in the future.

( août 02 2005, 03:12:39 PM CEST ) Permalink Comments [7]