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
nagivation.
* 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
parameters.
* 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...)
Regards,
Simon
