After more debugging, I learned some new things about wicket.

It appears that an invisible stateful link makes a page stateful.
The base page for this application contains a username label + logout link (stateful), which are in a WebMarkupContainer which is invisible if the user is not logged in. But in the end, even when it is invisble this link makes the entire page stateful.
When I remove that link wicket no longer performs a redirect to /login?0.

This leads me to two questions to the devs:

1) looking at this usecase, does it make sense that a stateful link which is not rendered makes the entire page stateful?

2) when a stateful page is accessed without a session (/login?0) by a client which does not support cookies, we get infinite redirects (/login?0 => /login => /login?0 => /login etc). Is this normal behavior?
This assumes that only cookie-based sessions are allowed.

Furthermore: (2) was not a problem in 1.5.0 (where /login?0 would not redirect back to /login if there was no session...). I understand the need for the redirect to /login?0, and love that (ajax changes are still available on back button, fantastic!). But, the redirect back from /login?0 to /login I don't get, especially when there is no session available.

Kind regards,

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




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to