FacesServlet URL Patterns

后端 未结 1 1255
悲哀的现实
悲哀的现实 2021-01-22 02:44

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:



        
相关标签:
1条回答
  • 2021-01-22 02:53

    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.

    0 讨论(0)
提交回复
热议问题