It might be worth the effort to refactor your code so that security checks are performed in the pageValidate() method. This is a pretty standard approach and benefits in part from the fact that the target page is already loaded when creating callbacks, etc. There's a simple example in the VLib app.

Each page class can create different types of callbacks (e.g. external vs. direct, varying parameters, etc.) by defining a createCallback method() in your base page class and overriding it as needed. pageValidate() invokes any security checks and calls createCallback() to hand a callback to the login page.

I used this approach with Acegi recently. It took a little work to replace the Acegi web filters, but the result is nicely integrated and easy to use.

-Ryan


Mike Snare wrote:
I'm writing an interceptor to perform authentication checks and I'm
contributing the interceptors to the major services (direct, asset,
page, etc).  If the user is not logged in I throw a
PageRedirectException to the login page.  If the page the user is
trying to view implements a marker interface specifying that it can be
returned to after login (I'm specifically not using external callback)
then the 'nextPage' attribute of the login page is set before throwing
the exception.  The Login page currently redirects back to the desired
page by name.

It's working fine, except for a couple of issues that may or may not
be fixable.  That's where I need some expert help.

The interceptor is invoked before the service method, so the page
hasn't really been set up yet.  The interceptor actually has to look
at the request parameters to find the name of the page we are going
to. It can't just call infrastructure.getRequestCycle.getPage. Another side effect of this early call is that none of the properties
on the page have been set up yet, so even if I wanted to use
ExternalCallback for pages that take parameters, I'm worried that I'm
going to run into problems when the page actually gets called back
because the ExternalCallback would be created in the interceptor (not
in the page) and so the service parameters would have to be added
as-is, in no particular order.  When the page gets called back it
would have no way of knowing how to extract the parameters from the
object array b/c it didn't specify the order.

If I could somehow force the page to initialize itsself I could make
it implement a method that knew how to take its parameters and create
a object array from them and return it.  Can I force the class to
implement itsself prior to the call to service()?

Anyone have any ideas?  My goal is to have as little work necessary
for individual page developers to get this to work for them.

It's almost 11 here, so pardon me if I'm not being particularly clear...

Thanks,
-Mike

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

Reply via email to