Martin,
Thanks for your pointer.
This is indeed the reason for the loop: no buffered response is found.
Something must have changed between 1.5.0 and 1.5.1 regarding (session)
cookies and continueToOriginalDestination(), since it is no longer
setting a session cookie.
For all our public-facing apps we force a HttpServletResponseWrapper
which does not allow the container to encode urls; The result in 1.5.0
was that we never get a jsessionid in the url, and there were no
side-effects.
Our login page is stateless; However, all other bookmarkable pages are
statefull and an RestartResponseAtInterceptPageException is thrown to
redirect to the login page, which creates a session.
I found a thread in which you commented that one should not use a
ResetResponseException (or a specialization of it) in combination with
cookies. So how would that work with a login page?
We log the user in as follows:
private void login( User user )
{
DSNSession session = getSession();
session.setUser( user );
session.bind();
System.out.println( session.getId() );
if( !continueToOriginalDestination() )
throw new RestartResponseException(
getApplication().getHomePage() );
}
Looking at wicket's own AuthenticatedWebSession & co, it's done exactly
the same there, so I wonder why it stopped working...
Sebastian
Op 22-3-2012 8:00, schreef Martin Grigorov:
Hi,
A hint for debugging: the request to login?0 should be handled by
org.apache.wicket.core.request.mapper.BufferedResponseMapper not by
WebPageRenderer. Check why there is no stored response.
A suggestion: try to make your login page stateless. Otherwise every
hit to your application will create a new http session. I.e. an
attacker can cause a denial of service.
On Thu, Mar 22, 2012 at 12:17 AM, Bas Gooren<b...@iswd.nl> wrote:
We have the following simple setup:
BasePage checks if user is logged in, if not (and this is not the
LoginPage), RestartResponseException(LoginPage.class);
LoginPage extends BasePage; contains a form to login;
The application runs in the root context.
Now on 1.5.0 this works like a charm;
After upgrading to 1.5.5 we get infinite redirects; testing versions in
between, we've found that the problem occurs>= 1.5.1;
Here's what debugging shows:
1) When we hit the root url (homepage), it redirects to /login
2) When the LoginPage (mounted at /login) is hit, WebPageRenderer:266
redirects from /login to /login?0
3) When /login?0 is hit, WebPageRenderer:214 redirects from /login?0 to
/login
and this loops back to (2)
I've also learned that this does not occur if we do not run the app in the
root context, so it appears to have to do with url handling.
Looking at the wicket 1.5.1 changelog I don't see anything that was changed
to break this.
Before doing more debugging, does anyone have a clue what might cause this?
Kind regards,
Sebastian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
