JSF Welcome File Gotcha’

19 December, 2006 (10:28) | JavaServer Faces

When using web.xml’s welcome file capability to specify your application home page, make sure your editor (hint: Eclipse Web Tools?) doesn’t put in a leading slash.

Right:

<welcome-file-list>
<welcome-file>homePage.jsf</welcome-file>
</welcome-file-list>

Wrong:

<welcome-file-list>
<welcome-file>/homePage.jsf</welcome-file>
</welcome-file-list>

The leading slash in the second example will trip up JSF such that when you submit a form on the home page, it will simply reload the home page on the first click, and then do the action and navigate to a new page only on the second click. If you look closely in the URL, you’ll see a // in the path that causes the problem. Welcome files work in any directory (thus, no slash is needed), but Eclipse WTP appears to add a preceding slash when using the file chooser.
Note: if you’re using Tomcat and specify a welcome file with a jsf extension as shown, you’ll also need to create a dummy file with that extension in addition to the real JSP or .xhtml (facelets) view template to satisfy Tomcat’s welcome file existence check. I create a .jsf file with a single line:

<%// Dummy file to trick Tomcat into supporting welcome-file-list –%>

/dmc

MyFaces Requiredness Checking Bug Resolved

19 December, 2006 (10:13) | JavaServer Faces

After *much* discussion, MYFACES-1467 has been resolved (see previous post). The patch did not break the Sun TCK as originally thought, so it went in as UIInput.java version 478342 on 11/22/06.

/dmc

Hacking JSF Requiredness Checking

14 October, 2006 (01:52) | JavaServer Faces, Web App Security

MyFaces committer Matthias Weßendorf and I spent a few minutes this afternoon at ApacheCon confirming what I suspected about validation of required values in JSF. Normally, if you leave a required field empty, it will show up as an empty string and JSF will properly check for requiredness. But if, for a given required field, you remove the name-value pair from the POST altogether using a man-in-the-middle tool (MITM), JSF will not detect the missing required field.  This is also an issue in the Sun RI and in fact results from unclear, if not conflicting, requirements in the JSF spec as detailed at the JIRA link below.
This issue is being tracked on the MyFaces JIRA https://issues.apache.org/jira/browse/MYFACES-1467, where you can also obtain the patch I’ve submitted.
/dmc

Securing MyFaces Applications Against the OWASP Top Ten

11 October, 2006 (06:03) | JavaServer Faces, Web App Security

My ApacheCon presentation is now available in the Security section of this site.

Using Tomahawk Tree2 Component in a Portal

26 September, 2006 (02:25) | JavaServer Faces

To run Tree2 with client-side expansion, you need JavaScript in the page <HEAD>. Normally, this gets added by the Tomahawk ExtensionsFilter. This doesn’t work in a portal, however, because servlet filters don’t run in a portal. There are some patches in MYFACES-434 (portlet filter) you may be able to use, but here’s an easier workaround. I’ve used this successfully with Tomahawk 1.1.3 in both Jetspeed2 and Liferay.

First, use Tree2 with server-side expansion so as not to require JavaScript. The ExtensionsFilter is therefore needed only to serve up the image resources needed by Tree2, and image requests are handled through the Faces Servlet, not the portal, so the ExtensionsFilter will run as normal for these requests. However, Tomahawk 1.1.3 checks to see if the ExtensionsFilter has been configured, which fails in the portal context. Fortunately, you can disable the check with a web.xml context param.

So to summarize, you can use Tree2 1.1.3 in a portal without any of the MYFACES-434 patches if

  1. You use server-side toggle
  2. You configure ExtensionsFilter as normal for the Faces Servlet
  3. You disable the ExtensionsFilter configuration check as follows in web.xml:
    <context-param>
         <param-name>org.apache.myfaces.CHECK_EXTENSIONS_FILTER</param-name>
         <param-value>false</param-value>
     </context-param>

/dmc

Securing MyFaces Against the OWASP Top Ten

15 September, 2006 (12:35) | Uncategorized

Presentation for ApacheCon US 2006

JSF Trick: Invoking an Action Method on an Item in a Datatable

9 September, 2006 (01:33) | JavaServer Faces

Suppose you want to create a table of items and enable one or more action links for each item; for example, a list of files with a “check out” and “delete” link next to each. The usual approach is to create a java.faces.model.ListDataModel in your backing bean and call its getRowData() method from the action method in your backing bean to get the item for which the action was taken. These are great JSF features, but I recently found you can avoid even this code.

The trick is to put your action method in the class that represents the item. Then you can reference it directly in the view template, like this:

<h:dataTable value="#{fileMgr.items}" var="item">
    <h:column>
        <h:outputText value="#{item.name}" />
    </h:column>
    <h:column>
        <h:commandLink value="Check out"
            action="#{item.actionCheckOut}" />
    </h:column>
</h:dataTable>

In this example, fileMgr is the backing bean, and item is the datatable var representing a model object. The trick here is that JSF will go ahead and call the actionCheckOut() method on the item object, even though it’s in a model class, not a backing bean. This way, you don’t even have to mess with ListDataModel.

Neat as this is, it is usually only appropriate in the case of simple toggle actions that affect only the item properties. Most other actions (especially delete) are likely to need references to the entire collection of items or other classes such as DAOs which you would not want to reference directly in a class representing a domain object such as an item. Still, it will save a layer of code for simple actions and I’m tickled that it works.

JSF for Struts Developers Online Registration Now Open

20 August, 2006 (03:04) | Uncategorized

Just a quick note for those who have been waiting for online registration for my upcoming class on JSF for Struts Developers in Atlanta. In order to give every student the best possible learning experience, registration is limited to 15 students.

Securing MyFaces Applications Against the OWASP Top Ten

18 August, 2006 (03:03) | JavaServer Faces, Web App Security

My presentation on this subject has been selected for the upcoming ApacheCon US 2006! If you’d like to be a technical reviewer beforehand, please e-mail me at the address on the Consulting menu above. See you there!

ApacheCon US 2006

The JavaServer Faces (JSF) API is an excellent foundation for building secure Web applications because of its component-oriented nature, carefulness surrounding data validation, and numerous extension points. Apache myFaces builds on this strength by providing components which offer built-in protection against many of the OWASP Top Ten attacks including form parameter tampering and cross-site scripting. In this presentation, we’ll review how myFaces protects against these attacks and move on to explore JSF extensions you can deploy to provide complete protection against the OWASP Top Ten, including forced browsing, information leakage in select boxes, and unauthorized method execution. Specifically, we’ll look at centralized approaches to ensuring that every field and form is properly validated, a phase listener and view handler to prevent forced browsing and assist with detection of session hijacking, a customer converter and component to hide sensitive information such as IDs in menu options, and a JAAS permission checker for component actions (event handler methods).

/dmc

Disable Browser Caching in JSF

8 August, 2006 (16:29) | JavaServer Faces, Web App Security

Browser caching of page content has negative security implications when your application runs on shared terminals (like the public library). You can turn it off with this simple phase listener.

package sandbox; import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import javax.servlet.http.HttpServletResponse;public class CacheControlPhaseListener implements PhaseListener {
public PhaseId getPhaseId() {
return PhaseId.RENDER_RESPONSE;
}
public void afterPhase(PhaseEvent event) {}
public void beforePhase(PhaseEvent event) {
FacesContext facesContext = event.getFacesContext();
HttpServletResponse response = (HttpServletResponse) facesContext.getExternalContext().getResponse();
response.addHeader(“Pragma”, “no-cache”);
response.addHeader(“Cache-Control”, “no-cache”);
response.addHeader(“Cache-Control”, “must-revalidate”);
response.addHeader(“Expires”, “Mon, 8 Aug 2006 10:00:00 GMT”); // some date in the past
}
}

I’ve now packaged this as a jar that you can just drop in to your JSF project. The jar includes a faces-config snippet so the phase listener automatically registers itself if the jar is present.

jsf-nocache-1.0.jar (JAR, 3 kB)