FacesServlet URL Patterns

Question

I am not sure what I am doing wrong here but when I put the faces context twice in the URL it bypasses all of my Realm Securities.

My URL Pattern:

<servlet-mapping>
    <servlet-name>Faces</servlet-name>
    <url-pattern>/faces/*</url-pattern>
</servlet-mapping>

Security Constraint

<security-constraint>
    <display-name>ADMIN</display-name>
    <web-resource-collection>
        <web-resource-name>Protected Admin Area</web-resource-name>
        <description/>
        <url-pattern>/faces/admin/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description/>
        <role-name>ADMIN</role-name>
    </auth-constraint>
    <user-data-constraint>
        <description/>
        <transport-guarantee>NONE</transport-guarantee>
    </user-data-constraint>
</security-constraint>

So when i goto: http://domain.com/faces/admin/index.xthml i do get the proper response i am looking for.

But if i goto: http://domain.com/faces/faces/admin/index.xhtml it completely lets me in regardless of the fact that the servlet is slated to be at /admin* I am assuming the * at the end of admin is what is causing it. But how can I solve this to where domain.com/faces/faces is invalid, and only domain.com/faces is valid?

I cannot seem to find anyone else facing this issue. So i must be doing something wrong.

Thank you

Answer 1

First, the good news: You're not doing anything wrong.

To solve: Use the extension mapping variant on the FacesServlet

<servlet-mapping>
   <servlet-name>Faces</servlet-name>
   <url-pattern>*.xhtml</url-pattern>
</servlet-mapping>

The bad news: This might be a bit of an oversight (read:flaw) in the request matching model.

My hypothesis is that the URL matching model of the FacesServlet doesn't work well with the standard servlet container request matching model.

---

In an ideal situation (without JSF), /faces/faces/admin/index.xhtml must correspond either a servlet or a specific resource. The container will attempt to verify if it's a valid resource and then whether the resource is a constrained resource.

The problem here is that the container takes the resource constraints very literally, meaning that it looks for the closest literal match to that URL in the security table. If it doesn't resolve the resource as being restricted, it serves the resource without interfering.

• When you define /faces/admin/* as a protected resource, request a /faces/faces/admin/admin.xhtml and then also have a /faces/* servlet mapping, the container attempts to verify that /faces/faces/admin/index.xhtml is a constrained resource (and it's not). Since the container has no reason to hold up the request any further, it hands the request over to FacesServlet and then FacesServlet appears to just blindly strip all references to faces in the requestURL (because you've said OK to /faces/*) and serve anything that's left.

• This is the reason why the file-extension servlet definition appears to be immune to it; in the case of the file extension mapping, the FacesServlet must find a literal resource in your folder structure that corresponds to that URL even before the container gets to determine that the resource is constrained or not

Verify this theory and there might be a need to file a critical JIRA with the mojarra team.