Prefix-based Faces Servlet and @Join syntax

Splash Forums Rewrite Users Prefix-based Faces Servlet and @Join syntax

This topic contains 1 reply, has 2 voices, and was last updated by  Lincoln Baxter III 3 years ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #24382

    0swald
    Participant

    Hi there.
    Not sure whether this is a bug or feature, but I have to use different view paths in beans and links. For example, here is simple bean:

    @ManagedBean
    @ViewScoped
    @Join(path = "/{lang}/", to = "/faces/pages/pub/home.xhtml")
    public class HomeBean {
    ....
    

    /faces/* – is a prefix-based url-pattern for Faces Servlet in web.xml.

    And here is how I have to create link to the home page:

    <h:link outcome="/pages/pub/home.xhtml">
      Go home
      <f:param name="lang" value="#{homeBean.lang}"/>
    </h:link>
    

    Please note – no ‘/faces’ prefix in link’s outcome. On the other hand, if I do use the prefix, I get the following warning in Glassfish logs (for each home link):

    com.sun.faces.application.view.MultiViewHandler normalizeRequestURI|JSF1015: Request path ‘/faces/pages/pub/home.xhtml’ begins with one or more occurrences of the FacesServlet prefix path mapping ‘/faces’.

    And the question is which style do I have to stick to – one that doesn’t match @Join‘s ‘to’ parameter, or the one that does not make Glassfish barfing on the links? ))

    PS: There is an interesting behavior if one does not use prefix in @Join‘s ‘to’ parameter – page source code is returned in response, which is kinda dangerous imho.

    #24391

    Typically the solution here is to remove the servlet mapping for /faces/* which causes other issues with such inconsistencies, and just stick with *.xhtml as the servlet mapping, which eliminates the vulnerability in JSF where anyone can request your sources. This way the servlet path is the same as the resource path, with nothing ‘virtual’ added in.

    It’s what I’ve always recommended people do even without Rewrite or PrettyFaces.

    Additionally, this problem exists if you simply type in the path on the URL – it’s not actually cause by Rewrite, so… shame on you JSF 🙂

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.

Comments are closed.