Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
On Mon, Mar 26, 2012 at 1:12 PM, Bas Gooren wrote: > Hi, > > Op 25-3-2012 18:59, schreef Martin Grigorov: >> >> On Sun, Mar 25, 2012 at 7:19 PM, Bas Gooren wrote: >>> >>> https://issues.apache.org/jira/browse/WICKET-4468 >> >> Thanks! >> We will consider it. >> >> >>> 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 ? > > After the redirect the currentUrl is "login?0" and the targetUrl is "login". > > So when a request comes in for "login" we fall through to the if/else at > line 264 since the targetUrl2 is "login?0"; So only after rendering the page > does wicket know it's stateful (makes sense). Right. > > When the request for "login?0" comes in, targetUrl is "login", since wicket > does not yet know the page is stateful and no buffered response is found. > Thus, the if/else at line 214 is triggered, which redirects to "login" > (targetUrl). > > So basically this is a chicken/egg problem: wicket won't know if the page is > stateful until after it is rendered. Due to some shortcuts at the top of > WebPageRenderer#respond() which ignore statefull/stateless differences we > get an infinite redirect loop. I'm not sure how to approach this. Neither jsessionid in cookie, nor in the url, and you want to reach a stateful page... Here are two options: 1) org.apache.wicket.settings.IRequestCycleSettings.RenderStrategy#ONE_PASS_RENDER global setting that says "don't make redirect after post" 2) org.apache.wicket.request.handler.RenderPageRequestHandler.RedirectPolicy#NEVER_REDIRECT use it with: requestCycle.scheduleRequestHandlerAfterCurrent(new RenderPageRequestHandler(new PageProvider(LoginPage.class), RedirectPolicy.NEVER_REDIRECT)) this will cause rendering of LoginPage without making a redirect cons: continueToOriginalDestination() wont work because there is no intercepted data > > > - > 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
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
Hi, Op 25-3-2012 18:59, schreef Martin Grigorov: On Sun, Mar 25, 2012 at 7:19 PM, Bas Gooren wrote: https://issues.apache.org/jira/browse/WICKET-4468 Thanks! We will consider it. 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 ? After the redirect the currentUrl is "login?0" and the targetUrl is "login". So when a request comes in for "login" we fall through to the if/else at line 264 since the targetUrl2 is "login?0"; So only after rendering the page does wicket know it's stateful (makes sense). When the request for "login?0" comes in, targetUrl is "login", since wicket does not yet know the page is stateful and no buffered response is found. Thus, the if/else at line 214 is triggered, which redirects to "login" (targetUrl). So basically this is a chicken/egg problem: wicket won't know if the page is stateful until after it is rendered. Due to some shortcuts at the top of WebPageRenderer#respond() which ignore statefull/stateless differences we get an infinite redirect loop. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
On Sun, Mar 25, 2012 at 7:19 PM, Bas Gooren wrote: > Hi, > > Op 25-3-2012 17:44, schreef Martin Grigorov: > >> Hi, >> >> On Sat, Mar 24, 2012 at 10:44 PM, Bas Gooren 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 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
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
Hi, Op 25-3-2012 17:44, schreef Martin Grigorov: Hi, On Sat, Mar 24, 2012 at 10:44 PM, Bas Gooren 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 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 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 Goorenwrote: 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
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
Hi, On Sat, Mar 24, 2012 at 10:44 PM, Bas Gooren 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 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
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
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 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
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
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 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
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
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 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 > -- 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
After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
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