FacesServlet URL模式 [英] FacesServlet URL Patterns

问题描述

我不确定我在这里做错了什么，但当我在网址中将两次面孔上下文绕过我的所有Realm证券时。

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.

我的网址格局：

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

安全约束

<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>

所以当我转到： http://domain.com/faces/admin/index.xthml 我得到了正在寻找的正确答案。

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

但如果我转到： http://domain.com/faces/ faces / admin / index.xhtml 它完全让我进入，不管servlet是否在/ admin *我假设在管理员结束时*是导致它的原因。但是，我如何解决这个问题，使domain.com/faces/faces无效，只有domain.com/faces有效？

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.

谢谢

推荐答案

首先，好消息：你没有做错任何事。

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

要解决：使用扩展程序映射 FacesServlet上的变体

To solve: Use the extension mapping variant on the FacesServlet

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

坏消息：这可能有点疏忽（阅读请求匹配模型中的：flaw）。

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

我的假设是 FacesServlet 的URL匹配模型没有与标准的servlet容器请求匹配模型配合良好。

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

在理想情况下（没有JSF）， /faces/faces/admin/index.xhtml 必须对应servlet或特定资源。容器将尝试验证它是否是有效资源，然后验证资源是否是受约束的资源。

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.

这里的问题是容器从字面上理解了资源约束非常，这意味着它会查找与该URL中最接近的文字匹配。安全表。如果它没有将资源解析为受限制，它会在不干扰的情况下为资源提供服务。

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.

• 定义时/ faces / admin / *作为受保护资源，请求 /faces/faces/admin/admin.xhtml ，然后还有 / faces / * servlet映射，容器尝试验证 /faces/faces/admin/index.xhtml 是一个受约束的资源（并且不是）。由于容器没有理由进一步提出请求，它将请求交给 FacesServlet 然后 FacesServlet 似乎只是盲目地删除了requestURL中对 faces 的所有引用（因为你已经说好了 / faces / *）并提供剩下的任何内容。

• 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.

这就是文件扩展名servlet定义似乎不受其影响的原因; 在文件扩展名映射的情况下， FacesServlet 必须在您的文件夹结构中找到与该URL对应的文字资源甚至在容器确定资源是否受限制之前

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

验证此理论并且可能存在需要向mojarra团队提交关键的JIRA。

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

这篇关于FacesServlet URL模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！