On Sun, Mar 25, 2012 at 7:19 PM, Bas Gooren <b...@iswd.nl> wrote: > Hi, > > Op 25-3-2012 17:44, schreef Martin Grigorov: > >> 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. > > https://issues.apache.org/jira/browse/WICKET-4468
Thanks! We will consider it. > > I've filed it as an improvement against wicket 1.5.5 since that's what we're > using. > >> >>> 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(). > > Ok: here's whats happening: > > - A request comes in for /login > - WebPageRenderer:264-266 stores the buffered response in the session and > redirects to /login?0 > - WebPageRenderer:214 redirects to /login, since that is what the target > page is mounted at > > So because no buffered response is found, the /login?0 url is processed by > the WebPageRenderer. It checks if the current url is "correct" for the > current page. If not, it redirects to the correct url. > > This can be a major problem when apps have bookmarkable stateful pages which > are opened by clients which do not support sessions. > > I encountered this bug as follows: > - I have my app in the root context of my tomcat server in eclipse WTP (web > tools) > - when I start tomcat through eclipse, WTP checks if the server is running > by requesting the "/" url > - Eclipse WTP performs the request with a sessionless client; We also force > wicket to never include jessionid in the url > - since this app requires authentication, "/" redirects to "/login" > - /login was (unexpectedly) stateful, due to a hidden "logout" link > - Eclipse WTP ended up in an infinite redirect loop, until it decided after > 30 seconds that tomcat was unable to start and kills the tomcat process > What are the values of currentUrl and targetUrl at the top of the method body at the second request (the redirect) ? I expect current to be login?0 because this is what is requested. I also expect the target url to be login?0 because the page is stateful (thus ?pageId) and is freshly constructed (thus pageId is again 0). Is this correct ? In which if/else clause it goes after that ? > >> >>> 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
