You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Mike Bresnahan <gu...@gmail.com> on 2014/08/26 23:44:08 UTC
Nested Redirects and REDIRECT_TO_BUFFER
Short story:
I have a scenario where the render strategy is REDIRECT_TO_BUFFER and there
are 2 nested redirects. The observed behavior is that the first page gets
displayed rather than the second page. The scenario goes like this:
1) A user logs in and goes idle.
2) The session expires
3) The user clicks on an AJAX button
4) Browser sends AJAX request to server
5) My AuthenticatedWebApplication.onException() override is called with an
instance of PageExpiredException and returns new
RenderPageRequestHandler(new PageProvider(new SessionTimeoutPage(null)));
6) Wicket renders SessionTimeoutPage and saves it in a buffer.
7) Wicket responds with an AJAX redirect order
8) Browser sends request for SessionTimeoutPage
9) For reasons I discuss below, my
AuthenticatedWebApplication.onBeginRequest() override tosses a custom
runtime exception.
10) My AuthenticatedWebApplication.onException() override is called with an
instance of the custom runtime exception and returns new
RenderPageRequestHandler(new PageProvider(new LandingPage(null)));
11) Wicket responds with the buffered response which contains
SessionTimeoutPage instead of rendering LandingPage and responding with the
result.
My observation is that SessionTimeoutPage is displayed to the user, but my
expectation is that LandingPage is displayed to the user.
I googled on the problem and also studied the source code
(WebPageRenderer.respond() in particular), but I did not any elegant way to
accomplish what I want. It seems that it is not possible to redirect more
than one time in a row when the render strategy is REDIRECT_TO_BUFFER. What
I did discover is that I can clear the render buffer by
calling WebApplication.getAndRemoveBufferedResponse(), but I am uneasy with
this solution since it seems like I am playing with Wicket internals;
albeit the function is public.
Is there a better way?
Long Story:
I am integrating Oracle Access Manager with a Wicket 1.5 app to enable a
sign-sign-on feature. OAM has a component called webgate that consists of a
Apache module. Requests from the browser travel through Apache/Webgate on
their way to the Wicket app running in WebLogic. Webgate redirects the user
to a login page if they are not authenticated. If the user is
authenticated, Webgate adds some HTTP headers to the requests that contain
information about the authenticated user (name, roles, etc). In the Wicket
session constructor I look for these headers and auto-sign-in the user if
they are present; effectively bypassing the Wicket application login page.
The first issue I encountered is that if the browser sends an AJAX call
when the OAM session has expired, OAM sends a 302 redirect to the OAM login
page and the browser ignores it. This causes the app to become unresponsive
when the user interacts with AJAX controls. I worked around this by
configuring OAM to not "protect" AJAX calls. This prevents redirects from
occurring during AJAX requests, but it also prevents the OAM headers from
being added to AJAX requests.
The second issue I encountered is that if the browser sends an AJAX call
when the Wicket session has timed out, the session constructor gets called
during the AJAX call when the headers are not present and thus the user
does not get auto-signed-in. Instead they are presented with the session
timeout page. I worked around this by adding additional code to the
AuthenticatedWebApplication.onBeginRequest() override that looks for the
OAM headers and tosses a custom runtime exception if they are detected and
code in onException() that redirects to the landing page.
Is there a better way?
Re: Nested Redirects and REDIRECT_TO_BUFFER
Posted by gudujarlson <gu...@gmail.com>.
https://issues.apache.org/jira/browse/WICKET-5689
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Nested-Redirects-and-REDIRECT-TO-BUFFER-tp4667175p4667249.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Nested Redirects and REDIRECT_TO_BUFFER
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Please create a quickstart app and attach it to JIRA.
The issue looks like https://issues.apache.org/jira/browse/WICKET-4433 but
it is different.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Aug 27, 2014 at 12:44 AM, Mike Bresnahan <gu...@gmail.com>
wrote:
> Short story:
>
> I have a scenario where the render strategy is REDIRECT_TO_BUFFER and there
> are 2 nested redirects. The observed behavior is that the first page gets
> displayed rather than the second page. The scenario goes like this:
>
> 1) A user logs in and goes idle.
> 2) The session expires
> 3) The user clicks on an AJAX button
> 4) Browser sends AJAX request to server
> 5) My AuthenticatedWebApplication.onException() override is called with an
> instance of PageExpiredException and returns new
> RenderPageRequestHandler(new PageProvider(new SessionTimeoutPage(null)));
> 6) Wicket renders SessionTimeoutPage and saves it in a buffer.
> 7) Wicket responds with an AJAX redirect order
> 8) Browser sends request for SessionTimeoutPage
> 9) For reasons I discuss below, my
> AuthenticatedWebApplication.onBeginRequest() override tosses a custom
> runtime exception.
> 10) My AuthenticatedWebApplication.onException() override is called with an
> instance of the custom runtime exception and returns new
> RenderPageRequestHandler(new PageProvider(new LandingPage(null)));
> 11) Wicket responds with the buffered response which contains
> SessionTimeoutPage instead of rendering LandingPage and responding with the
> result.
>
> My observation is that SessionTimeoutPage is displayed to the user, but my
> expectation is that LandingPage is displayed to the user.
>
> I googled on the problem and also studied the source code
> (WebPageRenderer.respond() in particular), but I did not any elegant way to
> accomplish what I want. It seems that it is not possible to redirect more
> than one time in a row when the render strategy is REDIRECT_TO_BUFFER. What
> I did discover is that I can clear the render buffer by
> calling WebApplication.getAndRemoveBufferedResponse(), but I am uneasy with
> this solution since it seems like I am playing with Wicket internals;
> albeit the function is public.
>
> Is there a better way?
>
> Long Story:
>
> I am integrating Oracle Access Manager with a Wicket 1.5 app to enable a
> sign-sign-on feature. OAM has a component called webgate that consists of a
> Apache module. Requests from the browser travel through Apache/Webgate on
> their way to the Wicket app running in WebLogic. Webgate redirects the user
> to a login page if they are not authenticated. If the user is
> authenticated, Webgate adds some HTTP headers to the requests that contain
> information about the authenticated user (name, roles, etc). In the Wicket
> session constructor I look for these headers and auto-sign-in the user if
> they are present; effectively bypassing the Wicket application login page.
>
> The first issue I encountered is that if the browser sends an AJAX call
> when the OAM session has expired, OAM sends a 302 redirect to the OAM login
> page and the browser ignores it. This causes the app to become unresponsive
> when the user interacts with AJAX controls. I worked around this by
> configuring OAM to not "protect" AJAX calls. This prevents redirects from
> occurring during AJAX requests, but it also prevents the OAM headers from
> being added to AJAX requests.
>
> The second issue I encountered is that if the browser sends an AJAX call
> when the Wicket session has timed out, the session constructor gets called
> during the AJAX call when the headers are not present and thus the user
> does not get auto-signed-in. Instead they are presented with the session
> timeout page. I worked around this by adding additional code to the
> AuthenticatedWebApplication.onBeginRequest() override that looks for the
> OAM headers and tosses a custom runtime exception if they are detected and
> code in onException() that redirects to the landing page.
>
> Is there a better way?
>