wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bas Gooren <...@iswd.nl>
Subject Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
Date Sat, 24 Mar 2012 20:44:22 GMT
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<bas@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>

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


Mime
View raw message