directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Interceptors and LDAP operations
Date Wed, 14 Sep 2005 20:24:07 GMT
Stefan Zoerner wrote:

> This is a question regarding the list of operations in the interface 
> Interceptor (org.apache.ldap.server.interceptor).
>
> I was wondering why it does not contain all LDAP operations (namely 
> extended and compare are missing). E.g. if I would like to implement 
> audit logs (e.g. for performance analysis), a natural idea would be to 
> create an AuditInterceptor. But I can't create audit logs on an LDAP 
> operation basis that way. I also noticed that these operations are not 
> included in the ContextPartition interface as well (here extended ops 
> make perhaps not that much sense ...).

Good point.  I have thought about this before.  However before I go on 
to address this concern let me explain why the interceptor methods are 
structured the way they are. 

The interceptor methods are not to mimic JNDI or even LDAP opperations.  
Notice that they're a mixture of the two really.  These methods were 
designed and distilled over several rewrites of the backend subsystem 
for efficiency and coherence.  For efficiency we have made sure the 
impedence mismatch between JNDI and LDAP are minimized and operations 
are process with a minimal set of methods.  Meaning Compare need not 
have a compare interceptor but can use a lookup and other functionality 
can determine if the condition is met.  Compare also is not a store 
operation (lookup is however) where these backend operations are concerned.

Hence the interceptor mechanism was designed to trap backend specific 
operations not LDAP operations.  This does however lead to a problem if 
you want to use it for LDAP operation specific auditing purposes.  This 
is why we need to define a session object and have that tracking which 
LDAP operation was performed way up in the protocol provider so 
interceptors can make some decisions on the availability of this 
information.

Now realize one thing: LDAP the line protocol may not be used.  Remember 
the server side JNDI provider may be used in embedded mode within an 
application.  This way operations against the server may not have had an 
equivalent protocol operation.  The application may not even expose the 
LDAP protocol turning the LDAP service ProtocolProvider off in MINA.  
All operations may be via the server side JNDI provider which knows 
nothing about Compare operations.

So this session information may or may not be present and interceptors 
must make sure they can handle that.  This session information will help 
solve the problems you are referring to below as well ...

> How is it planned to implement Controls or a custom extended 
> operation? An interceptor would be an option, but it is probably 
> difficult to implement rules like "this request control may be sent 
> along with ops x,y and z", if the original ops do not map to the life 
> cycle of the interceptor.
>
> Or is it intended to plug a controls component near the handlers of 
> the LDAP operations (e.g. CompareHandler in 
> org.apache.ldap.server.protocol).

Again this can be done in the interceptors or within the protocol 
handlers themselves.  If you ask me I think part of it will be within 
handlers and part of it will be managed by interceptors.  If done within 
the interceptor we're going to need to give the LDAP specific request 
information to the interceptor somehow.  This is where the session and 
request information mentioned above will come in handy.

I know this is somewhat hazy but its undefined territory.  So any ideas 
or recommendations in this space is welcome.

Thanks,
Alex
 

Mime
View raw message