You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Bas Gooren <ba...@iswd.nl> on 2012/03/21 23:17:05 UTC
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple
problem
Posted by Bas Gooren <ba...@iswd.nl>.
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<ba...@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
>>
>
>
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Mar 26, 2012 at 1:12 PM, Bas Gooren <ba...@iswd.nl> wrote:
> Hi,
>
> Op 25-3-2012 18:59, schreef Martin Grigorov:
>>
>> On Sun, Mar 25, 2012 at 7:19 PM, Bas Gooren<ba...@iswd.nl> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple
problem
Posted by Bas Gooren <ba...@iswd.nl>.
Hi,
Op 25-3-2012 18:59, schreef Martin Grigorov:
> On Sun, Mar 25, 2012 at 7:19 PM, Bas Gooren<ba...@iswd.nl> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
Posted by Martin Grigorov <mg...@apache.org>.
On Sun, Mar 25, 2012 at 7:19 PM, Bas Gooren <ba...@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<ba...@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<ba...@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
>>>
>>
>>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple
problem
Posted by Bas Gooren <ba...@iswd.nl>.
Hi,
Op 25-3-2012 17:44, schreef Martin Grigorov:
> Hi,
>
> On Sat, Mar 24, 2012 at 10:44 PM, Bas Gooren<ba...@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
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 Gooren<ba...@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
>>
>
>
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Sat, Mar 24, 2012 at 10:44 PM, Bas Gooren <ba...@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<ba...@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
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple
problem
Posted by Bas Gooren <ba...@iswd.nl>.
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<ba...@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
Re: After upgrading from wicket 1.5.0 to 1.5.1+ we have a simple problem
Posted by Martin Grigorov <mg...@apache.org>.
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 <ba...@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
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org