PageCallback and login issue (tapestry weakness?)

[Henri Dupre <he...@gmail.com>]

One thing where I am not very satisfied with tapestry is to implement an
authentication support.
I don't need anything fancy, I just want some pages where the user is
authenticated and others that don't require authentication.
And I'd like the authentication to be transparently implemented: I provide a
login page that gets called when the authenticated page get called (by any
type of link, some ExternalLinks other PageLinks). Right now I've
implemented this by subclassing: I have an "AuthenticatedPage" class that
has a pageValidate method.
This method checks if the user is authenticated and if so do nothing
(display the page) or else redirect the user to a login page and provide a
callback to the page.

First trouble: this scheme doesn't work with ExternalLinks. The
activateExternalPage, gets called *after* page validate. So in this scheme,
the paramters passed to the external link get lost and the
activateExternalPAge never called.

Second trouble: Callbacks. Since I can't use external links for this schema,
I tried to implement another way for a page to keep its property after it
gets called back. Each page can provide (by overriding a method) its own
callback. Sounds not too bad, but I discovered that a PageCallBack discards
the properties values!

One thing I was wondering is why is it so akward to implement an
authentication theme?
Why couln't tapestry take care of most of these mechanics? I bet they are
the same for everyone. I read here that someone implemented an
authentication interceptor that seems to do exactly that.

For instance, Tapestry could provide a standard way for a page to say that
it requires authentication. And provide some authentication API.
And whatever type of link is used, take care of the whole callback stuff
(for a page link, this would simply mean storing the page properties, and
for an external link store the parameters).

Right now, without some more API, I find it difficult to implement a scheme
properly since a PageRedirectException only works properly in pageValidate.

How did other people here implement an authentication theme?


Thanks,

Henri.

Re: PageCallback and login issue (tapestry weakness?)

[D&J Gredler <dj...@gmail.com>]

I'm not sure, but it sounds like you might be wanting to mix concerns a bit
too much. We're using Acegi and it has worked well, though the learning
curve is a bit steep.

On 5/2/06, Henri Dupre <he...@gmail.com> wrote:
>
> One thing where I am not very satisfied with tapestry is to implement an
> authentication support.
> I don't need anything fancy, I just want some pages where the user is
> authenticated and others that don't require authentication.
> And I'd like the authentication to be transparently implemented: I provide
> a
> login page that gets called when the authenticated page get called (by any
> type of link, some ExternalLinks other PageLinks). Right now I've
> implemented this by subclassing: I have an "AuthenticatedPage" class that
> has a pageValidate method.
> This method checks if the user is authenticated and if so do nothing
> (display the page) or else redirect the user to a login page and provide a
> callback to the page.
>
> First trouble: this scheme doesn't work with ExternalLinks. The
> activateExternalPage, gets called *after* page validate. So in this
> scheme,
> the paramters passed to the external link get lost and the
> activateExternalPAge never called.
>
> Second trouble: Callbacks. Since I can't use external links for this
> schema,
> I tried to implement another way for a page to keep its property after it
> gets called back. Each page can provide (by overriding a method) its own
> callback. Sounds not too bad, but I discovered that a PageCallBack
> discards
> the properties values!
>
> One thing I was wondering is why is it so akward to implement an
> authentication theme?
> Why couln't tapestry take care of most of these mechanics? I bet they are
> the same for everyone. I read here that someone implemented an
> authentication interceptor that seems to do exactly that.
>
> For instance, Tapestry could provide a standard way for a page to say that
> it requires authentication. And provide some authentication API.
> And whatever type of link is used, take care of the whole callback stuff
> (for a page link, this would simply mean storing the page properties, and
> for an external link store the parameters).
>
> Right now, without some more API, I find it difficult to implement a
> scheme
> properly since a PageRedirectException only works properly in
> pageValidate.
>
> How did other people here implement an authentication theme?
>
>
> Thanks,
>
> Henri.
>
>

Re: PageCallback and login issue (tapestry weakness?)

[Mike Snare <mi...@gmail.com>]

Unfortunately, no.  It's all proprietary stuff for my company.  Sorry.

I'll be glad to help you with any problems you run into coding it up,
but I can't post mine.  I can, however, tell you that I based my
interceptor factory on the interceptor factory for creating logging
interceptors.

I order to keep the code generation simple, I would also recommend
putting as much of the actual interception logic in a standard service
or class as possible, using the generated interceptor merely as a
hook.  It greatly simplifies debugging.

-Mike

On 5/5/06, Henri Dupre <he...@gmail.com> wrote:
> On 5/3/06, Mike Snare <mi...@gmail.com> wrote:
> >
> > Henri,
> >
> > This same issue has been discussed before (search the archives for my
> > name and authentication), but I'll summarize what I've done and how it
> > works -- and how it doesn't work.
> >
> > I've created an authentication interceptor that I attach to all the
> > major engines.  It simply checks for an authenticated user and throws
> > a RedirectException to the login page if none is found.  It also tells
> > the login page where to go after a login.  I have an external
> > configuration file that can be used by a page designer to flag that
> > his/her page should NOT be authenticated.  By default, all pages are.
> >
> > The problem is timing.  The authenticator gets called before the page
> > is set up, and thus a callback can't be created.  (I, too, ran into
> > the PageCallback issue trying to overcome this).  There is an
> > enhancement request (TAPESTRY-892) that Jessee is looking at to enable
> > us to force the setup of a page specifically for this reason (and
> > others I haven't thought of).
> >
> > This approach isn't perfect, but depending on how your pages operate,
> > does a good deal of the work for you.
>
>
> This sounds quite good. I was just thinking that these features would be
> nice to have directly inside the tapestry framework since I bet that it
> would suit the needs of 90% of people. I hope to see something happening
> about your enhancement request because this is also where I'm stuck right
> now. Is there any chance to see your code and hivemind configuration?
>
> Thanks,
>
> Henri.
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: PageCallback and login issue (tapestry weakness?)

[Henri Dupre <he...@gmail.com>]

On 5/3/06, Mike Snare <mi...@gmail.com> wrote:
>
> Henri,
>
> This same issue has been discussed before (search the archives for my
> name and authentication), but I'll summarize what I've done and how it
> works -- and how it doesn't work.
>
> I've created an authentication interceptor that I attach to all the
> major engines.  It simply checks for an authenticated user and throws
> a RedirectException to the login page if none is found.  It also tells
> the login page where to go after a login.  I have an external
> configuration file that can be used by a page designer to flag that
> his/her page should NOT be authenticated.  By default, all pages are.
>
> The problem is timing.  The authenticator gets called before the page
> is set up, and thus a callback can't be created.  (I, too, ran into
> the PageCallback issue trying to overcome this).  There is an
> enhancement request (TAPESTRY-892) that Jessee is looking at to enable
> us to force the setup of a page specifically for this reason (and
> others I haven't thought of).
>
> This approach isn't perfect, but depending on how your pages operate,
> does a good deal of the work for you.


This sounds quite good. I was just thinking that these features would be
nice to have directly inside the tapestry framework since I bet that it
would suit the needs of 90% of people. I hope to see something happening
about your enhancement request because this is also where I'm stuck right
now. Is there any chance to see your code and hivemind configuration?

Thanks,

Henri.

Re: PageCallback and login issue (tapestry weakness?)

[Mike Snare <mi...@gmail.com>]

Henri,

This same issue has been discussed before (search the archives for my
name and authentication), but I'll summarize what I've done and how it
works -- and how it doesn't work.

I've created an authentication interceptor that I attach to all the
major engines.  It simply checks for an authenticated user and throws
a RedirectException to the login page if none is found.  It also tells
the login page where to go after a login.  I have an external
configuration file that can be used by a page designer to flag that
his/her page should NOT be authenticated.  By default, all pages are.

The problem is timing.  The authenticator gets called before the page
is set up, and thus a callback can't be created.  (I, too, ran into
the PageCallback issue trying to overcome this).  There is an
enhancement request (TAPESTRY-892) that Jessee is looking at to enable
us to force the setup of a page specifically for this reason (and
others I haven't thought of).

This approach isn't perfect, but depending on how your pages operate,
does a good deal of the work for you.

-Mike

On 5/2/06, Henri Dupre <he...@gmail.com> wrote:
> One thing where I am not very satisfied with tapestry is to implement an
> authentication support.
> I don't need anything fancy, I just want some pages where the user is
> authenticated and others that don't require authentication.
> And I'd like the authentication to be transparently implemented: I provide a
> login page that gets called when the authenticated page get called (by any
> type of link, some ExternalLinks other PageLinks). Right now I've
> implemented this by subclassing: I have an "AuthenticatedPage" class that
> has a pageValidate method.
> This method checks if the user is authenticated and if so do nothing
> (display the page) or else redirect the user to a login page and provide a
> callback to the page.
>
> First trouble: this scheme doesn't work with ExternalLinks. The
> activateExternalPage, gets called *after* page validate. So in this scheme,
> the paramters passed to the external link get lost and the
> activateExternalPAge never called.
>
> Second trouble: Callbacks. Since I can't use external links for this schema,
> I tried to implement another way for a page to keep its property after it
> gets called back. Each page can provide (by overriding a method) its own
> callback. Sounds not too bad, but I discovered that a PageCallBack discards
> the properties values!
>
> One thing I was wondering is why is it so akward to implement an
> authentication theme?
> Why couln't tapestry take care of most of these mechanics? I bet they are
> the same for everyone. I read here that someone implemented an
> authentication interceptor that seems to do exactly that.
>
> For instance, Tapestry could provide a standard way for a page to say that
> it requires authentication. And provide some authentication API.
> And whatever type of link is used, take care of the whole callback stuff
> (for a page link, this would simply mean storing the page properties, and
> for an external link store the parameters).
>
> Right now, without some more API, I find it difficult to implement a scheme
> properly since a PageRedirectException only works properly in pageValidate.
>
> How did other people here implement an authentication theme?
>
>
> Thanks,
>
> Henri.
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org