On Mon, Mar 26, 2012 at 1:12 PM, Bas Gooren <b...@iswd.nl> wrote:
> Hi,
>
> Op 25-3-2012 18:59, schreef Martin Grigorov:
>>
>> On Sun, Mar 25, 2012 at 7:19 PM, Bas Gooren<b...@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-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

Reply via email to