myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: Redirection problem after login
Date Mon, 23 Apr 2007 02:46:17 GMT
Sly_cardinal wrote:
> Sly_cardinal wrote:
>> ...
>> Simple example of what is happening:
>> - User logs in, navigates to page1.
>> - Session is lost (either timeout or server restart).
>> - User attempts to navigate to page2.
>> - Tomcat redirects to login page; user logs in.
>> -- At this point Tomcat should process the previous request and navigate
>> to page2; instead it returns to page1.
>> faces-config.xml:
>> <navigation-rule>
>>         <navigation-case>
>>             <from-outcome>go_agent_list</from-outcome>
>>             <to-view-id>/agent/agentList.jsp</to-view-id>
>>         </navigation-case>
>>         ...
>> </navigation-rule>
>> In JSP page:
>> <t:commandNavigation2 value="Agent List" action="go_agent_list" />
> We've done some logging and have found that the NavigationHandler does not
> receive any navigation action after the user logs in from an invalid
> session. We believe that the following events occur:
> 1. User logs in, navigates to a page.
> 2. Session is invalidated (e.g. server is restarted or session times out).
> 3. User attempts to navigate to another secure page:
> - Page attempts to post navigation request to itself.
> - Session is invalid, requires login, cannot post navigation request.
> - User redirected to login page.
> - User logs in.
> - Server returns to page that initiated the request; navigation request does
> not exist, server does not redirect.
> Is this something we will have to live with by using the NavigationHandler
> or can someone suggest an alternative navigation implementation we could use
> when the user is required to login prior to handling navigation?

I expect that what is happening is:

* browser sends http post to page1.jsf, including parameters that 
indicate that some button was clicked that would normally trigger 

* if tomcat detects that the user is logged in then normal processing 
occurs; JSF restores the view from the http session then processes the 
post parameters. This triggers an action that causes an internal forward 
to page2.jsp, ie the user sees the second page.

* if tomcat detects that the user isn't logged in then it remembers the 
requested url ("page1.jsf") posted parameters and forwards to the login 
page instead.
* user enters name/pwd and triggers a submit to the special 
"j_security_check" url. Tomcat verifies login, then creates a new http 
session and forwards to the remembered url ("page1.jsf") + original 
* JSF tries to restore the view from the http session, but it's empty so 
"restore view" fails. JSF cannot do any "postback" processing without a 
restored view, so instead just the "render" phase executes, ie page1.jsf 
is rendered.

In short, if you're using server-side state saving (ie in the http 
session) and the http session is discarded (login expires) then a jsf 
submit will not work. The behaviour is the same even without security 
constraints; it's the loss of the http session that is the problem.

You could use client-side state saving, but that probably won't work for 
a different reason: as described above, tomcat "caches" a post request 
that failed due to security and replays it after successful login. But 
it has an upper limit on the amount of data it will cache, and the 
vlient-side state stuff stored in hidden fields is typically larger than 
that so the saved view gets lost this way too.

I don't know any simple solution to this. For the system I'm currently 
working on we use javascript to trigger a function every 5 minutes that 
uses XMLHttpRequest to perform a GET of a simple page from the server. 
This keeps the user's session alive as long as the browser window isn't 
closed. Of course this script needs to be present in every page (which 
happens to be easy for us as we use SiteMesh anyway...)



View raw message