Hi, On Sat, Mar 24, 2012 at 10:44 PM, Bas Gooren <b...@iswd.nl> wrote: > 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?
This is a good point. I think Wicket's logic to decide whether something is stateful could be improved to ignore invisible and disabled components/behaviors. Those should not be reachable anyway. Please file a ticket. > > 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. I'll have to debug the application to see what happens exactly. Try to debug it in org.apache.wicket.request.handler.render.WebPageRenderer#respond(). > > 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 > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
