On the contrary, there's no code duplication involved - the logic is
defined only once in a base page. If the only thing your pages have in
common is the need to perform security checks, then that could be the
sole purpose of the base page (and only protected pages need to extend
it). Every protected page does indeed end up performing the security
check, but in your approach so does every service invocation. In
fact,any validation scheme must be invoked on every page request so
there's also no net difference in the amount of code execution whether
it's done at the page level, service level, or in the container.
Your approach requires duplicating code (or at least HiveMind
configuration) for each service, which doesn't seem to be better
practice than factoring common page behavior into a base class. All I'm
really advocating here is the approach recommended by Howard in TIA and
demonstrated in the Vlib app, and I always assumed this was the standard
way to implement security checks in Tapestry (not that "standard" means
it's the best or even good, just that it's not unusual).
If you're open to the idea of using a base page, I can probably help you
with any specific issues you might have.
-Ryan
Mike Snare wrote:
That certainly would work, but it seems to go against good practice on
a number of levels, most importantly is that the same code (am i
logged in ? continue : go to login with a possible callback) gets
duplicated in every page. I'd hate to force every page to do this and
I definitely don't want to use a base page, some pages may not need a
base class at all...
There are options that could make that work, I just don't see one I like.
Thanks,
-Mike
On 3/23/06, Ryan Holmes <[EMAIL PROTECTED]> wrote:
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]
---------------------------------------------------------------------
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]
