How do I protect JSF 2.0 facelets against direct access?

Question

I have found one idea here, putting files under /WEB-INF is a way to block direct access:

With Facelets, one can also put XHTML files under the /WEB-INF, if they are templates or included files (same restrictions as with JSP essentially).

The page also presents a solution based on Java EE security, which allows direct XHTML access only to members of a specific user group.

<security-constraint>
    <display-name>Restrict XHTML Documents</display-name>
    <web-resource-collection>
        <web-resource-name>XHTML</web-resource-name>
        <url-pattern>*.xhtml</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Only let 'developer's access XHTML pages</description>
        <role-name>developer</role-name>
    </auth-constraint>
</security-constraint> 

Would you recommend one of these solutions, or are both generally used?

Answer 1

Putting in the /WEB-INF folder is only applicable for template files, include files and tag files which should never be accessed directly and standalone by URL, also not by a valid mapping.

The security constraint is only applicable for public files when you haven't mapped the FacesServlet on *.xhtml. If you have for example mapped it on *.jsf then you can open public resources by foo.jsf URLs, but one could retrieve the raw XHTML source code by just changing the extension to foo.xhtml. That security constraint prevents this.

But better is to just map the FacesServlet on *.xhtml directly. This way you don't need that security constraint anymore. However, template/include/tag files should still be placed in /WEB-INF folder. To get the general idea, you may find the source of the OmniFaces showcase project helpful (see WEB-INF here).

See also:

• Which XHTML files do I need to put in /WEB-INF and which not?
• JSF files inside WEB-INF directory, how do I access them?

Answer 2

It is extremely plausible that .xhtml can be placed under and served from the web information folder.

I would instead of relying on decorative programming such as putting rules into web.xml, look into security solution such as JSecurity to provide JAAS for my application.