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

/dmc

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

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.

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

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)