Hi Andre,
On Oct 21, 2008, at 9:55 AM, Andre Juffer wrote:
I would also be interested to understand how this would work with
cocoon 2.2. The SessionModule, see http://cocoon.apache.org/2.2/core-modules/sitemap-components/1.0/apidocs/org/apache/cocoon/components/modules/input/SessionModule.html
may be the answer.
meh... see below.
My problem is the following. I need to evaluate whether or not a
given user is allowed to access certain files or to perform certain
tasks. With Spring's capabilities of AOP (Aspect Oriented
Programming), it is very easy to define aspects, pointcuts, and
joint points, currently defined on certain service classes in the
domain. Typically, before a requested task is carried out (call to
service class method), the system 'jumps' to a policy class to check
whether or not the user is in fact allowed to perform the task. If
so, the system continues with the requested task, otherwise for
instance an exception is raised.
The policy class implements a PolicyEvaluator interface (totally
unaware of cocoon), which is the one that the AOP works with.
So far so good...
I would now need an implementation of PolicyEvaluator that needs to
identify the requesting user. So, this could possibly be
accomplished with the SessionModule, like
PolicyEvaluatorImpl extends SessionModule implements PolicyEvaluator {
private UserRepository userRepository;
PolicyEvaluatorImpl(UserRepository userRepository)
{
super();
this.userRepository = userRepository;
}
// From PolicyEvaluator
public boolean isAllowed(...)
{
// Get the requesting user.
Long identifier = (Long) super.getAttribute("identifier");
User user = this.userRepository.getUser(identifier);
// Apply policies here.
String reason = ....;
if ( !notAllowed )
throw new PolicyException(reason);
return true;
}
}
Would this actually work? Note that I use Spring for creating all
objects, including the PolicyEvaluatorImpl. Spring, by default would
instantiate this class as a singleton (which is fine with me), but I
must be quite sure that the current Session is available to the
implementing class.
No, it won't work... you can't just instantiate an InputModule like
that, and also the getAttribute() method takes other parameters
besides just the attribute name, which refer to Cocoon internal stuff.
But also, w.r.t. the whole idea... it's sort of like taking the whole
gorilla when all you want is the banana :-). The purpose of an
InputModule is to inject data into a sitemap pipeline, and
SessionModule has a bunch of apparatus (inherited from
AbstractJXPathInputModule) to implement that, and it would be weird to
create a class extending SessionModule for some other purpose, i.e. to
not use any of the intended purpose of SessionModule but just to use
it as a way to access the session object. Much better to figure out
how things in Cocoon access the session object and then do like they
do. Somebody here should be able to help you out with that...
My current implementation include in their signature the User
object. In some cases this is not convenient (also gives coupling
between packages, which possibly could be avoided) and I am
therefore looking for an alternative solution.
I don't what the signature thing is about, so I can't comment...
cheers,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
