JSF - Redirecting the page via web.xml

[Bruno John Mccoy]

Guys, I have a question that I don't know how to solve. I have a JSF web project where pages that do not require authentication are in WebContent, and pages that require login are in WebContent / logged

So, when I set the error-page in Web.xml to redirect the user in case of error 404 or 500 from the server, I need to inform the path of the xhtml page that should be requested and shown to the user. But, it doesn't work for both. Only for one case. Only when the erros occours in the same folder that the xhtml page is set in the project.

My web.xml:

<error-page>
       <error-code>404</error-code>
       <location>/logged/errormsg404.xhtml</location>
    </error-page>
    <error-page>
       <error-code>500</error-code>
       <location>/logged/errormsg404.xhtml</location>
</error-page>

if I'm browsing a page and try to access a resource that doesn't exist and that isn't inside WebContent / logged /, the site redirects me to the page, the page opens, but doesn't load the css.

However, if I am logged in and access a page that pops up error 404 or 500 from the server, the user is redirected to the page that, in turn, opens correctly with the images and css.

How do I make this work if the error has caused a page that is outside the WebContent / logged / folder?

thank you

[Vincenzo Palazzo]

How you load the CSS inside your error page?

[Bruno John Mccoy]

vincenzo palazzo wrote:How you load the CSS inside your error page?

Hi vincenzo.

I have two pages in .xhtml for error 404 and 500 in these followings folders with their respective css paths:

WebContent -> Name of the page: errorSession.xhtml. Css path: <link href="resources/bs2/css/style.css" rel="stylesheet"/>

WebContent/logged -> Name of the page: errorSession.xhtml. Css path:  <link href="../resources/bs2/css/style.css" rel="stylesheet"/>


All the pages css in WebContent/logged works fine, except the errorSession.

[Vincenzo Palazzo]

In my opinion, I think the error is

href="../resources/bs2/css/style.css"

When I use JSF I write the reference with the request.contextPath, like this

<link rel="stylesheet" href="#{request.contextPath}/css/personal.css" type="text/css" />

In my cases, the CSS is inside the application root, if your resources dir is in your root, try to use this code.

P.S: My I miss my JSF rules and I don't test this solution, but should be a test.

[Tim Holloway]

I'm still trying to make sense of this.

I've got a nasty suspicion that this app is using a DIY security system and not the JEE standard security. JEE standard security avoids the issues of having to manually determine what should be done when a request or request component is unauthorized. It is also much, much less likely to get hacked. As in, I know of no documented cases of JEE security breakage, unlike virtually every DIY system - many of which can be bypassed in 10 minutes or less by unskilled users.

I don't recommend using JSF for error pages, or for that matter, for any page served out of web.xml - especially login/loginfail pages. Page/resource references in web.xml are served directly by the web application server, not via the normal external request/response system and in particular that has historically meant that the request would not go through the FacesServlet. JSPs and HTML are safe. JSF Views, I'm less certain about.

And, of course, any javascript, images, CSS or other sub-request items should not be secured if they would be requested from a page that is not secure. As a very common example, a login page should not have secured JavaScript, CSS or images, since the login page itself is not yet authenticated. So JEE standard security would loop forcing a login on the secured JavaScript, CSS and/or images.

[Tim Holloway]

Bruno John Mccoy wrote:
WebContent -> Name of the page: errorSession.xhtml. Css path: <link href="resources/bs2/css/style.css" rel="stylesheet"/>

You really should be using JSF's own resource resolution tags for this kind of stuff. It gets rid of a lot of problems, and as a bonus, promotes "skinning".

[Bruno John Mccoy]

Tim Holloway wrote:

Bruno John Mccoy wrote:
WebContent -> Name of the page: errorSession.xhtml. Css path: <link href="resources/bs2/css/style.css" rel="stylesheet"/>

You really should be using JSF's own resource resolution tags for this kind of stuff. It gets rid of a lot of problems, and as a bonus, promotes "skinning".

Hey guys!

Apparently, there is another alternative to redirect the user to a specific page when an error occurs on the server and this must be implemented in the java itself instead of the web xml. If any of you have any code that can help me. I tried to do this by creating the following class:

public class CustomExceptionHandlerFactory extends ExceptionHandlerFactory {

	@Override
	public ExceptionHandler getExceptionHandler() {
		// TODO Auto-generated method stub
		return null;
	}
    private ExceptionHandlerFactory parent;
 
    public CustomExceptionHandlerFactory(ExceptionHandlerFactory parent) {
        this.parent = parent;
    }
 
    @Override
    public ExceptionHandler getExceptionHandler() {
        ExceptionHandler handler = new CustomExceptionHandler(parent.getExceptionHandler());
        return handler;
    }
 
}

public class CustomExceptionHandler extends ExceptionHandlerWrapper {

	@Override
	public ExceptionHandler getWrapped() {
		// TODO Auto-generated method stub
		return null;
	}
 
    private ExceptionHandler wrapped;
   
    final FacesContext facesContext = FacesContext.getCurrentInstance();
    
    final Map requestMap = facesContext.getExternalContext().getRequestMap();
     
    final NavigationHandler navigationHandler = facesContext.getApplication().getNavigationHandler(); 
    
    CustomExceptionHandler(ExceptionHandler exception) {
        this.wrapped = exception;
    } 

    @Override
    public ExceptionHandler getWrapped() {
        return wrapped;
    } 
    
    @Override
    public void handle() throws FacesException {
 
        final Iterator iterator = getUnhandledExceptionQueuedEvents().iterator();
        while (iterator.hasNext()) {
            ExceptionQueuedEvent event = (ExceptionQueuedEvent) iterator.next();
            ExceptionQueuedEventContext context = (ExceptionQueuedEventContext) event.getSource();
            
            Throwable exception = context.getException(); 

            try {

                
                requestMap.put("exceptionMessage", exception.getMessage());
 
             
                FacesContext.getCurrentInstance().addMessage(null, new FacesMessage
                    (FacesMessage.SEVERITY_ERROR, "The URL does not exists.", ""));
 
                
                FacesContext.getCurrentInstance().addMessage(null, new FacesMessage
                    (FacesMessage.SEVERITY_INFO, "You can keep using the system normally.", ""));
 
               
                navigationHandler.handleNavigation(facesContext, null, "/logged/errormsg404.faces");
 
                
                facesContext.renderResponse();
            } finally {
            
                iterator.remove();
            }
        }
        
        getWrapped().handle();
    }
}

Then, adding to faces-config.xml

<factory>
  <exception-handler-factory>
     br.com.semeru.exceptions.CustomExceptionHandlerFactory
  </exception-handler-factory>
</factory>

It works to logged users and non-logged users, but the page is blank, it means not even a word is shown, neither css or imagems, when in fact it should bring the image informing the user that the page he requested does not exist / there was an error on the server.

[Bruno John Mccoy]

Tim Holloway wrote:I'm still trying to make sense of this.

I've got a nasty suspicion that this app is using a DIY security system and not the JEE standard security. JEE standard security avoids the issues of having to manually determine what should be done when a request or request component is unauthorized. It is also much, much less likely to get hacked. As in, I know of no documented cases of JEE security breakage, unlike virtually every DIY system - many of which can be bypassed in 10 minutes or less by unskilled users.

I don't recommend using JSF for error pages, or for that matter, for any page served out of web.xml - especially login/loginfail pages. Page/resource references in web.xml are served directly by the web application server, not via the normal external request/response system and in particular that has historically meant that the request would not go through the FacesServlet. JSPs and HTML are safe. JSF Views, I'm less certain about.

And, of course, any javascript, images, CSS or other sub-request items should not be secured if they would be requested from a page that is not secure. As a very common example, a login page should not have secured JavaScript, CSS or images, since the login page itself is not yet authenticated. So JEE standard security would loop forcing a login on the secured JavaScript, CSS and/or images.

Hi There Tim!

Well, actually my web application has class managedBean(@SessionScoped) which controls the loggin in the system through Session, and i also have Filter classes that controls it. The problem i'm tryin to solve is how to make the redirected page show its css when  an 404 or 500 server erros occours while the user is browsing or tries to access a resource that doesnt exists outside of the WebContent/logged folder (in this case, error 404).

My filters for loggin works fine. Look:

@WebFilter("/auth/login.xhtml")
public class LoginFilter implements Filter {

	public LoginFilter() {
	}

	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
			throws IOException, ServletException {

		HttpServletRequest req = (HttpServletRequest) request;
		HttpServletResponse res = (HttpServletResponse) response;
		HttpSession session = (HttpSession) req.getSession();

		Login loggedUserSt = (Login) session.getAttribute("loggedUser");
		
		if (loggedUserSt == null) {
			chain.doFilter(request, response);
		} else {			
			res.sendRedirect(req.getContextPath() + "/logged/dashboard.xhtml");
		}
		
	}

	public void destroy() {
	}

	public void init(FilterConfig fConfig) throws ServletException {
	}
}

@WebFilter("/logged/*")
public class AppFilter implements Filter {

	public AppFilter() {
	}

	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
			throws IOException, ServletException {

		HttpServletRequest req = (HttpServletRequest) request;
		HttpServletResponse res = (HttpServletResponse) response;
		HttpSession session = (HttpSession) req.getSession();

		Login loggedUserSt = (Login) session.getAttribute("loggedUser");

		if (loggedUserSt == null) {
			res.sendRedirect(req.getContextPath() + "/auth/login.xhtml");

		} else {
			chain.doFilter(request, response);
		}
	}

	public void destroy() {
	}

	public void init(FilterConfig fConfig) throws ServletException {
	}
}

What I mean is that the automatic redirect does not load the page's css when a 404 or 500 error occurs if the user tries to access a resource that is outside the WebContent / logged / folder, as the web.xml configuration is not accepting two statements. If I do, the page is blank and not even the html of it opens.

<error-page>
       <error-code>404</error-code>
       <location>/logged/errormsg404.xhtml</location>
    </error-page>
    <error-page>
       <error-code>500</error-code>
       <location>/logged/errormsg404.xhtml</location>
    </error-page>
    
    <error-page>
       <error-code>404</error-code>
       <location>/errormsg404.xhtml</location>
    </error-page>
    <error-page>
       <error-code>500</error-code>
       <location>/errormsg404.xhtml</location>
    </error-page>

[Tim Holloway]

As I said. Use the JEE container security system, not a do-it-yourself system. Security is hard. I've worked with JEE since before JSPs were invented and about 90% of the user-designed login systems I've seen could be easily defeated. And that includes the ones designed by the in-house "genius". Financial, military, didn't matter. Security is a full-time job, not something to do "in addition" to writing the application. Even security professionals see their hard work defeated periodically, much less dilettantes.

There's just way too much coding being considered here, and I don't mean only login coding. Rule #1 in JSF is that the more JSF-specific code your app has, the more likely it is that you're not using JSF effectively. Most well-written JSF apps use nothing from javax.faces except for the model classes (DataModel and SelectItem). In cases where I need direct access to raw HTTP services (such as JEE beans that cannot be injected and JEE security API methods), I get by with a single utility class - which not only keeps the FacesContext out of casual code, it also can be easily mocked for offline testing.

JEE has lots of advanced features, but I rarely use them. Because I rarely actually need them. Plus a few of them are crap, and I'll avoid them until they get replaced by a cleaner standard in some future release. Which will probably break the crap stuff, if the JSF1-to-JSF2 transition has been any guide.

Also, just to complete the rant, I recommend avoiding raw HTML on JSF View Template (xhtml) files. JSF usually has an equivalent that works better and is better integrated into the JSF process. For example, the JSF resource tags don't have to know the application context path that the webapp is deployed under. They handle it automatically.

[Bruno John Mccoy]

Tim Holloway wrote:As I said. Use the JEE container security system, not a do-it-yourself system. Security is hard. I've worked with JEE since before JSPs were invented and about 90% of the user-designed login systems I've seen could be easily defeated. And that includes the ones designed by the in-house "genius". Financial, military, didn't matter. Security is a full-time job, not something to do "in addition" to writing the application. Even security professionals see their hard work defeated periodically, much less dilettantes.

There's just way too much coding being considered here, and I don't mean only login coding. Rule #1 in JSF is that the more JSF-specific code your app has, the more likely it is that you're not using JSF effectively. Most well-written JSF apps use nothing from javax.faces except for the model classes (DataModel and SelectItem). In cases where I need direct access to raw HTTP services (such as JEE beans that cannot be injected and JEE security API methods), I get by with a single utility class - which not only keeps the FacesContext out of casual code, it also can be easily mocked for offline testing.

JEE has lots of advanced features, but I rarely use them. Because I rarely actually need them. Plus a few of them are crap, and I'll avoid them until they get replaced by a cleaner standard in some future release. Which will probably break the crap stuff, if the JSF1-to-JSF2 transition has been any guide.

Also, just to complete the rant, I recommend avoiding raw HTML on JSF View Template (xhtml) files. JSF usually has an equivalent that works better and is better integrated into the JSF process. For example, the JSF resource tags don't have to know the application context path that the webapp is deployed under. They handle it automatically.

Thank you Tim!