> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
>
> Vadim Gritsenko wrote:
>
> >>But the servlet spec doesn't allow a servlet to set the user
> >>credential in the container.
> >>
> >
> >It will be set for you by the container.
> >
>
> There'a misunderstanding here : if authentication is performed by an
> Action,
I never said that. If by an action - see below - there is nothing in the
spec.
> the container has already given us a request, and we cannot give
> it back the user info computed by this action.
>
> >Servlet spec 2.3, SRV.12.5.3 Form Based Authentication:
> > 4. The container attempts to authenticate the user
> > using the information from the form.
> >
> >If you want to do this by yourself, then yes, it is not specified in
the
> >spec how to do this. But spec implementations usually provide you
with
> >the (non-statndard) way to handle this correctly (i.e. it will
propagate
> >Principal you provided into the container). I remember some examples
> >from the Bea WebLogic server.
> >
> That's precisely what I'd like to avoid : write an authenticator for
> each and every servlet engine my app has to run on, including those I
> know nothing about :(
>
> This is IMHO a major problem in J2EE. Could JAAS help here ?
IIRC, JAAS know is part of the J2EE. Am I right? Then yes, it must be
the missing link here.
> >Not good; This would not be propagated to the other environments,
say,
> >into an EJB. Not to say that this is against any standards Java has.
> >And, same could be done using session:
> >
> > public Principal getUserPrincipal() {
> > if (session.getAttribute("userPrincipal") == null) {
> > return request.userPrincipal;
> > } else {
> > return session.getAttribute("userPrincipal");
> > }
> > }
> >
> Do you mean this code could be the one in Cocoon's Request object ?
> Well, this avoids adding a setter, but the session then becomes a
> "hidden setter". And this changes nothing for EJBs.
O, no, never. It should go into your business logic. I do not like an
idea of cluttering Cocoon request.
> BTW, Servlet 2.3 introduces Filters what allow wrapping of the Request
> and Response :
> - what if a request wrapper changes the result of getUserPrincipal ?
> Will it be propagated to EJBs ?
Don't know about it. Even more, I doubt it.
> - shouldn't we have something similar in our abstracted environment ?
Don't know. We already have something like this for cocoon: protocol. Do
you want something else/more?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
