h:commandlink request uri does not change

[Gina vernon]

I have the following issue with h:commandlink tag:

My dir structure is as follows
_App Contx
|
|_ _css
|
|_ _protected pages
|
|
Welcome.page

I have page (pg1) in the protected folder that uses an h:commandlink. The link uses an action method and jsf navigation rules to navigate to another page(pg2) in the protected folder.
A custom filter filters all protected requests. When I click the link in pg1, the rquest uri that is sent to the filter is ../protected/pg1 instead of ../protected/pg2. So, the user stays in pg1.
I tried various usecases- I moved pg1 out of the protected folder and the link works.I used and it works. Only when both pages are in the same folder the URI does not change.

[Tim Holloway]

If what you're talking about is the URL displayed in the browser navigation bar, that's NOT a pointer to a specific View, it's a handle on the JSF context.

To get the URL to update, add the "redirect" element to the navigation action. it's extra overhead, but it does change the displayed URL, as well as establishing the absolute View context, which is important for bookmarking and for container-managed security.

[Gina vernon]

Tim, I do have the redirect tag in the navigation rule. This happens inspite of it. When the filter intercepts the request generated by clicking the link, the URI of the request is pg1 not pg2. Again I do have the redirect in the navigation rule.

[Tim Holloway]

If I read that properly, that's because you're applying the filter on the direct return from the form, and the redirect hasn't been applied yet. If you look closer, I think you may see 2 passes through the filter, and the second pass will be the redirected one.

[Gina vernon]

Tim, negative on that. There is only one pass through the filter. I debugged it very closely several times. And even if it somehow did go through twice, the request should go to the second page, it doesn't. It goes into an unending loop in the filter. Here is the filter code

    public void doFilter(ServletRequest request,
                         ServletResponse response,
                         FilterChain chain) throws IOException, ServletException 
    {
      HttpServletRequest httpRequest = (HttpServletRequest) request; 
      HttpServletResponse httpResponse = (HttpServletResponse) response; 
      String requestedPage = aHttpRequest.getRequestURI(); 
      Object authenticated = httpRequest.getSession().getAttribute("auth");
      
      if( (authenticated!=null)&&(authenticated.equals("yes"))) 
      {
        chain.doFilter(httpRequest, httpResponse);
        
      }     
      else       
      { 
        if(requestedPage.indexOf("pg2.xhtml")>-1 | requestedPage.indexOf("pg3.xhtml")>-1) 
        {
          chain.doFilter(httpRequest, httpResponse);
        }
          else
        {
        httpResponse.sendRedirect("../pg1.xhtml"); 
        }
      }

    }
    

[Gina vernon]

Nevermind. It works now.

[Tim Holloway]

You know, I think it must have been 3 whole days since I've make a comment on why Do-It-Yourself security systems are not only an oxymoron, but expensive to boot.

OK. got that out of my system.

There are limits to what I can deduce here without having actual hands on the code and running app, but there are a couple of observations I can make.

One of which is that you're testing for ".xhtml" strings. Normally, the URL doesn't have an "xhtml" in it, since that's a war resource file extension, not a URL component. My webapps normally end their JSF URLs with ".jsf", which web.xml has been instructed to resolve by locating and processing the corresponding ".xhtml" file. A lot of people confuse resource component names with URL component names, since syntactically, they're pretty much the same. However, functionally, they're as different as apples and tomatoes.

Which means, in short, that I'm not sure whether you're examining each and every URL that comes through the filter in your debugger. I think there should be some other indications than what you're reporting and I don't know if they're not there or if you simple don't see what you're not looking for. You might want to write all the URIs out to the log for debugging purposes.

Couple of basic programming hints, though. Doesn't affect behaviour but it makes code simpler.

1. If you say if( "yes".equals(authenticated) ), you'll save a few keysrtokes and a test, since "yes".equals(null) returns false. No need for a separate null test.

2. You should be able to replace requestedPage.indexOf("pg2.xhtml")>-1 with requestedPage.endsWith("pg2.xhtml"). Again, a little tidier and perhaps a tad more efficient. However, as I said above, "xhtml" is normally a resource file suffix, not a URL component, so I'd expect this clause to always return false.