[Top] [All Lists]

Re: Authentication check interceptor

Subject: Re: Authentication check interceptor
From: "Mike Snare"
Date: Thu, 23 Mar 2006 06:20:55 -0500
That would rock.

As to the triggerDirect, do you mean I would be able to actually take
a page that meets my requirements and trigger a direct to a method
(effectively calling the method) without having to render the page? 
That would work ok, i think.


On 3/22/06, Jesse Kuhnert <jkuhnert@xxxxxxxxx> wrote:
> That sounds pretty damn clear. I don't know if it's in the last release, but
> there is a method on DirectService at least that is called "triggerDirect"
> or something else similar..It would allow you to do what you describe.
> If not that, I wouldn't be opposed to adding an extension point of some sort
> into these services that would guarentee the page is loaded, but not yet
> rendered . (nor any methods called on it yet)
> Some sort of extendable method that contains the params needed to do your
> worst to the render chain. Would this help? We can probably get it into
> 4.0.1, which will be coming out very soon.
> jesse
> On 3/22/06, Mike Snare <mikesnare@xxxxxxxxx> 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: tapestry-user-unsubscribe@xxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: tapestry-user-help@xxxxxxxxxxxxxxxxxx
> >
> >
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.  http://opennotion.com

To unsubscribe, e-mail: tapestry-user-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: tapestry-user-help@xxxxxxxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>