cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [RT] Access Control (was [RT] Cocoon as OS)
Date Thu, 07 Feb 2002 21:03:52 GMT
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> 
> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message