Tim Holloway wrote:You have made the common mistake of confusing resource paths with URL paths. A resource is a "file" or a "directory" within a WAR. A URL is what the user enters on the client side. The webapp uses HTTP URL requests to construct HTTP Responses, and may reference resources to do so according to whatever rules it wishes. For example, a JSF URL is used as the basis for constructing a Resource path and the Faces Servlet locates the View Template it will use by using that path.
The security mechanism acts on incoming URLs, not on resources. So your view-Id's should be ....jsf, not ....xhtml.
Also. I suspect you are trying to use JSF for your login and loginfail web form pages. Because the container dispatches these pages directly, they don't go through the FacesServlet. Even if they did, the login logic in not user-written code - it's built into the server - so the idea of a JSF login page is questionable at best.
One thing to note in JSF is that since URLs often don't directly track the resources that are requested and since the security system keys on URLs, you should code a "redirect" option on any navigation to a secured page to force the URL to align itself.
Tim Holloway wrote:You cannot use the builtin security in conjunction with user-written login code. As I said earlier, when the container manages the security, the container also manages the login process. Login is done by the container shunting a URL request for a protected URL aside, having the container present and process the login/loginfail pages, then resuming the original URL request if the login succeeds.
The view-id element values in faces-config are relative URLs (relative to the application context root) without parameters on them. The View templates are xhtml. The FacesServlet is responsible for parsing the URL (.jsf) to locate the corresponding template (.xhtml).
Tim Holloway wrote:I always use container-managed security, so forbidding access to URLs that end with ".xhtml" is sufficient for me.
If you cannot use the container security system, the next best bet is to install a servlet filter to reroute the offending URLs to an error page. But that won't make the app any more secure.