If your JSF application uses the standard Java Servlet security mechanisms (<security-role>, <security-constraint>, <login-config>, et al), and your application allows a mixture of public and non-public access, you’ll probably want to make the JSF resource library available to the browsers of both public and non-public users.
Assuming that you’re using the JSF resource library mechanisms (like <h:outputStylesheet>), you’ll need this security constraint:
[xml] Public Resources /javax.faces.resource/*
If (like me) you’re mixing use of JSF tags like (<h:outputStylesheet>) with some direct references to resources, you’ll also want to include a URL pattern that allows that direct access:
[xml] Public Resources /javax.faces.resource/* /resources/*
Since these security constraints don’t specify an auth constraint, they are accessible to any browser that requests them. As noted, you can still include a <user-data-constraint> to enable SSL, if you like.
Having trouble getting Glyphicons to work with JavaServer Faces (JSF) 2.x?
You’re probably using the JSF resource mechanism to include the Bootstrap stylesheets and scripts:
When you use these tags, the resulting link that is included in the page looks like this:
Note that the href doesn’t contain the actual path to the stylesheet resource. When the browser requests this resource, the Faces servlet is going to interpret the request URI and query parameters to figure out which resource is needed.
So now what happens if this stylesheet contains relative URLs? Glyphicons are defined by font resources that need to be loaded by the browser. If we look at the non-minified bootstrap.css, we can see that it uses relative URLs to reference the necessary font resources:
Of course, the Faces servlet doesn’t know how to interpret this request. In fact, depending on how you’ve configured the <servlet-mapping/> for the Faces servlet, it might not even be asked to handle this request.
Since the URL for the font resource doesn’t correspond to the path of an actual resource in your Faces application, the browser gets a 404 when it makes this request, and consequently the Glyphicons in your application are all broken.
The easy solution is to use an ordinary <link> instead of using <h:outputStylesheet>. In this case:
Note that I’m using an EL expression to get the context path, and simply appending the path to the actual stylesheet resource in my application. Now, the relative URLs in the stylesheet will work just fine (assuming that I put Bootstrap’s fonts folder alongside the css folder).
If you really want to use the JSF resource mechanism, you’re going to need to modify the URLs in the Bootstrap’s font face definition. Obviously, you’re going to want to work with the non-minified version of the stylesheet here.
You might be surprised that you can use an EL expression inside of a stylesheet, in the same way that you would in a facelet page. The idea here is to replace each of the relative URLs in the font face definition with an EL expression that will produce a Faces-compatible URL:
Each expression uses the resource EL implicit object, which is a Map whose keys are composed of a JSF library name and a resource name, separated with a colon character.
The JSF resource mechanism doesn’t necessarily play well with third-party stylesheets and scripts. In my opinion, the need to modify a third-party stylesheet is sufficient reason to avoid using <h:outputStylesheet/> in such cases. However, if you’re really set on using the JSF resource mechanism, you can use EL expressions to replace relative URLs and make it all work.