Strange problem - I'm using authorization filter to check for access rights of a user when resource is requested. If a user is logged in as admin, he is redirected to a page where the contents of his personal dir is displayed. It works ok, but when a regular user is logged in, the page which is supposed to show directory contents returns famous "Cannot find FacesContext" error.
Directory contents is showed in an htmLib iframe component which is bind to a backing bean property - everything works ok here since it shows the right directory contents for admin. In authorization filter I use the following code:
I added logging to check for errors, and everything works till chain.doFilter, so it seems that there is no problem in authorization filter either. Can someone please help?
Show what runtime string does this --> httpRequest.getContextPath() + Constants.LOGIN_VIEW creates for both the options (i.e. admin / normal user).
Also, show the piece of code from web.xml where you have mapped your FacesServlet with URL pattern.
I feel probably you are missing "/faces/" in your url somewhere. Not sure though. [ June 06, 2005: Message edited by: Varun Khanna ]
Joined: Jun 06, 2005
Thanks for trying to help, I appreciate it!
This is from web.xml:
But I'm trying to load a directory contents in an iframe (which is processed by the Tomcat default servlet and does not contain any JSF code), not a JSF page, if that makes any difference. And requesting every other page (using .jsf extension) works ok.
As for the first part, I'm not sure I understand what you mean - that part of the code redirects the user to the login page if it discovers that user is not logged in at all and in my case returns "/DMSsajt/login.jsf" for both admin and normal user.
The main thing that I don't understand is that if an admin is logged in everything works ok, and the only thing that is different for a regular user is in authorization filter. And I tried to trace the error by logging the progress through auth. filter and it goes ok just until chain.doFilter.
This whole thing is pretty tough to figure out, so thanks a lot for trying to help
Joined: Jun 06, 2005
OK, althought I still don't know why it didn't work like that, I managed to get it to by changing servlet mapping to "/faces/*", adjusting all the redirects and faces-config.xml navigation to have the "faces/" prefix. Now it works totally ok.
Thanks for giving me the idea to try that in your post, anyway