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
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<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
