Can you expound upon how you plug in the WebRequestFilter.
Constructing the WebRequest subclass looks simple enough, and the
Callback factory dosn't seem too tough, but injecting a web request
filter sounds like hivemind magic that I'm unaware of.
This seems like something we'd want to provide a more accessible
solution for in the core tapestry framework. It is a fairly common
requirement of webapps. Preserving the state of the current HTTP
request so that it can be restored in a callback later seems to me
like something that we'd want to make very easy.
--sam
On 10/20/06, Jeff Lubetkin <[EMAIL PROTECTED]> wrote:
Not sure if this will help, but here's how we handle this (it's kinda
complicated, but it works):
* All of our callback generation for interstitial processes like login
go through a Callback factory service. In order to preserve URL
integrity for bookmarking and the like, we use an ICallback
implementation that sends a redirect to the browser.
* When a callback needs to be generated for a POST, or a GET that is too
long, the current request parameters (from
HttpServletRequest.getParameterMap) are stored in session, along with a
randomly-generated token. The parameters are stripped from the request
and the token is added as a the "postToken" parameter
("www.zillow.com/foo?postToken=123").
* We have a WebRequestFilter that handles "global" URL parameters that
can appear on any request. This custom URL handling code sees the
"postToken" parameter and creates a wrapper WebRequest that returns the
saved parameters from the getParameterNames, getParameterValue, and
getParameterValues methods (passing the rest of the methods through to
the wrapped WebRequest). This causes the request to look just like it
did before being sent off for authentication. Rewind/render happens
just as expected. The only difference is that (in the POST case) the
method will be GET rather than POST in the callback, but that rarely
matters.
The code for this is in no state to share, but hopefully the idea helps.
jeff
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam
Gendler
Sent: Friday, October 20, 2006 2:15 PM
To: Tapestry users
Subject: Re: Recovery of session during pageValidate
I can think of a couple of ways of doing this. The way I do this is to
use an ExternalCallback, store that in session, and after successful
authentication, I just execute the callback. However, this only works
if you use ExternalLinks, and doesn't work at all if someone submits a
form after being away from their computer for long enough to lose their
session.
Here's what would be really useful, but doens't actually work,
currently:
If you have their serviceParameters, you shouldn't need to put them back
in a request via the URL of the age, I think. You should just be able
to do something like this in your listener after they've successfully
authenticated:
@Persist
public abstract IPage getPreviousPage(); public abstract void
setPreviousPage(IPage page)
@Persist
public abstract Object[] getStoredServiceParameters(); public abstract
void setStoredServiceParameters(Object[] params);
public void doSomething(IRequestCycle cycle) {
// check auth here
if (authSuccess) {
cycle.setServiceParameters(getStoredServiceParameters());
cycle.activate(getPreviousPage());
return;
}
}
Unfortunately, when a page is activated, it doesn't go through a rewind
cycle, so even if the service parameters have all the right info (and
I'm not sure they do), the fields of your new page would not be
populated with the data.
I never found a solution to this, so my app has ExternalLinks everywhere
I can get them, and if you submit a form hours after you loaded it, you
just have to suffer through the process of filling it out again
manually. It is more than a little frustrating, but after fighting with
this problem for a good long while, I gave up on it.
I'd love to find a way to force a page to go through the entire
rewind/render cycle programmatically from a listener on another page,
but there doesn't seem to be a way to do this.
--sam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
