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
- Re: Interceptors and LDAP operations Alex Karasulu
-
