You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Dineth Chalitha Basnayaka <di...@gmail.com> on 2017/12/19 10:02:50 UTC
Re: Access LDAPmessage
Hi Emmanuel,
After a long time. I hope you can remember me. :-)
Your previous answer was very helpful for continuing my project and
achieved some milestone. Here I got the user data from LDAP entry and store
those things into different types of databases like MySQL. Now I need to
build a message response.When I'm going to do that I got the problem "get a
message ID at the interceptor level". Here, I tried using
context(eg-addContext) parameter to get the message ID. But I could not get
it. I would like to know am I missed something or are there have any
limitations to get the message ID at the interceptor level.
Thanks
Dineth.
[image: dinethr.PNG]
Dineth Chalitha Basnayake.
Undergraduate in Computer Science & Technology,
Uva Wellassa University of Sri Lanka
dinethchalitha@gmail.com
[image: facebook.png] <https://www.facebook.com/dineth.basnayake>[image:
Linked in alt.png]
<https://www.linkedin.com/in/dineth-chalitha-basnayake-a79032ba/>[image:
github.png] <https://github.com/DinethUWU>
On Sun, Aug 6, 2017 at 10:02 AM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> You are very welcome !
>
> Precise questions deserve precise answers :-)
>
>
> Le 06/08/2017 à 05:38, Dineth Chalitha Basnayaka a écrit :
> > Hi !
> >
> > Thank you for taking the time to help me, I really do appreciate it. This
> > explanation is really helping me improve.
> >
> > Thanks a lot!
> >
> >
> >
> > [image: dinethr.PNG]
> >
> > Dineth Chalitha Basnayake.
> >
> > Undergraduate in Computer Science & Technology,
> >
> > Uva Wellassa University of Sri Lanka
> >
> > dinethchalitha@gmail.com
> >
> > [image: facebook.png] <https://www.facebook.com/dineth.basnayake>[image:
> > Linked in alt.png]
> > <https://www.linkedin.com/in/dineth-chalitha-basnayake-a79032ba/>[image:
> > github.png] <https://github.com/DinethUWU>
> >
> > On Sun, Aug 6, 2017 at 7:34 AM, Emmanuel Lécharny <el...@gmail.com>
> > wrote:
> >
> >> Now, that's better :-)
> >>
> >>
> >> Although &.5 and 2.0.0-M24 are very different, the interceptor
> >> architecture hasn't change so much (hopefully). Ok, the doc is totally
> >> otdated, and we don't use the server.xml fila anymore.
> >>
> >>
> >> Interceptors are all extending the BaseIntercapor abstract class which
> >> itself implements the Interceptor interface. There is not that much you
> >> need to implement in your ow interceptor :
> >>
> >> - the init() method if you need to initialize some things when the
> >> interceptor is added to the system (it's called once at startup)
> >>
> >> - the destroy() method that is called when teh server is shutdown, would
> >> you need to cleanup things (AFAICT, no interceptor implements this
> method)
> >>
> >> - and a method for each LDAP operation : add, bind, compare, delete,
> >> getRootDse (SEARCH), hasEntry (SEARCH), lookup (SEARCH), modify, move
> >> (MODRDN), moveAndRename(MODRDN), rename (MODRDN),search and unbind. As
> >> you can see, some of those methods are a specific version of a base
> >> method - like lookup/hasEntry/getRootDSE which could be done using teh
> >> search method-, for convenience.
> >>
> >> Eachof the Operation methods use a special Context parameter, which
> >> itself gives you access to various elements :
> >>
> >> - the specific operations parameters (like the base DN or the filter for
> >> the search operation (check each of the Context classes and interfaces)
> >>
> >> - the Session (and here, the CoreSession).
> >>
> >>
> >> When an LdapMessage is received, the protocol handlers passes it to the
> >> CoreSession instance, which creates an operation context from it,
> >> extracting all the required pieces that are going to be processed by
> >> interceptors. At this point, the initial LdapMessage is not anymorz
> >> available from inside interceptors, bt can be rebuilt from the content
> >> of the operation context - including the controls -.
> >>
> >> The Session is also where you'll find information about each current
> >> operation, and the executing LDAP session. Typically, it gives you
> >> access to the caller's ID - the principal -, it's IP address,
> >>
> >>
> >> Now, once you have implemented your interceptor, there are two things
> >> that need to be done in the configuration :
> >>
> >> - each interceptor is declared in the configuration file
> >>
> >> - each one has an order in the chain
> >>
> >> - each one is either enabled or disabled
> >>
> >> - each interceptor is associated with a class implementing it
> >>
> >>
> >> The order is critical, and you must add yours at the right place,
> >> dependning on what you want to do. Usuammy, you want to add your
> >> inteceptor at the very end of the chain, so with the highest order. The
> >> order is stored in the ads-interceptororder attribute (see later for an
> >> example). The class implementing the interceptor is stored using its
> >> FQDN in the ads-interceptorclassname attribute.
> >>
> >> The interceptor will be called only if it's enabled, something that has
> >> to be set using the ads-enabled attribute.
> >>
> >>
> >> Here are two examples for two different interceptors :
> >>
> >>
> >> - The Normalization interceptor :
> >>
> >> dn:
> >> ads-interceptorId=normalizationInterceptor,ou=interceptors,ads-
> >> directoryServiceId=default,ou=config
> >> objectclass: top
> >> objectclass: ads-base
> >> objectclass: ads-interceptor
> >> ads-interceptororder: 1
> >> ads-interceptorclassname:
> >> org.apache.directory.server.core.normalization.NormalizationInterceptor
> >> ads-interceptorid: normalizationInterceptor
> >> ads-enabled: TRUE
> >>
> >> Its order is 1, it's the very first interceptor being called. The FCQN
> >> (org.apache.directory.server.core.normalization.
> NormalizationInterceptor)
> >> for this interceptor is stored in the ads-interceptorclassname
> >> attribute, and this interceptor is enabled.
> >>
> >>
> >> - The KeyDerivation interceptor :
> >>
> >> dn:
> >> ads-interceptorId=keyDerivationInterceptor,ou=interceptors,ads-
> >> directoryServiceId=default,ou=config
> >> objectclass: top
> >> objectclass: ads-base
> >> objectclass: ads-interceptor
> >> ads-enabled: FALSE
> >> ads-interceptororder: 8
> >> ads-interceptorclassname:
> >> org.apache.directory.server.core.kerberos.KeyDerivationInterceptor
> >> ads-interceptorid: keyDerivationInterceptor
> >>
> >> This interceptor is used when Kerberos is enabled, to compute the
> >> derived kerberos keys when a user changes its password.
> >>
> >> It's position is 8, becuase it has to be executed before the
> >> passwordHashing Interceptor, but here, as yu can see, it's disabled : it
> >> won't be executed at all.
> >>
> >>
> >> It's enough to set your configuration file with your interceptor for
> >> this interceptor to be automaticaly called at the right place in teh
> >> chain of interceptors : the server uses reflection at startup to know
> >> where to set it - if it's enabled - and for which operation it will be
> >> called (if you don't have a delete() method in your interceptor, for
> >> instance it will never be called when a user sends a Delete operation to
> >> the server). The configuratio is processed at startup, btw, so you'll
> >> need to restart the server if you change the configuration.
> >>
> >>
> >> I hope it helps.
> >>
> >>
> >>
> >> Le 05/08/2017 à 20:19, Dineth Chalitha Basnayaka a écrit :
> >>> Hi !
> >>>
> >>> I am very new to apacheDS so forgive me if I am interrupting you. I
> tried
> >>> with tutorial "Implementing a simple custom Interceptor for ApacheDS" (
> >>> http://directory.apache.org/apacheds/advanced-ug/6-
> >> implementing-interceptor.html)
> >>> . It was nice explanation and it work for me. But it related
> >> apcheds-1.5.5.
> >>> When its come to apacheds2.0.0-M24 I saw
> >>> org.apache.directory.server.core.hash.PasswordHashingInterceptor and
> >> more
> >>> default interceptors are already implement there.
> >>> So now I'am trying to implementing my own interceptor. In order to get
> >> the
> >>> interceptor installed in a default installation of ApacheDS2.0.0-M24
> >> little
> >>> bit confused me. Because there have some different with
> >> ApacheDS2.0.0-M24
> >>> and apcheds-1.5.5 installation layouts.In ApacheDs2.0.0-M24
> installation
> >>> layout not showing the server.xml file. If you can give some
> information
> >> to
> >>> install new Custom interceptors to apacheDS.2.0.0-M24 Its really
> helpful
> >>> for me.
> >>>
> >>> Thanks for your consideration.
> >>>
> >>>
> >>>
> >>>
> >>> [image: dinethr.PNG]
> >>>
> >>> Dineth Chalitha Basnayake.
> >>>
> >>> Undergraduate in Computer Science & Technology,
> >>>
> >>> Uva Wellassa University of Sri Lanka
> >>>
> >>> dinethchalitha@gmail.com
> >>>
> >>> [image: facebook.png] <https://www.facebook.com/dineth.basnayake
> >[image:
> >>> Linked in alt.png]
> >>> <https://www.linkedin.com/in/dineth-chalitha-basnayake-a79032ba/
> >[image:
> >>> github.png] <https://github.com/DinethUWU>
> >>>
> >>> On Fri, Aug 4, 2017 at 10:22 AM, Emmanuel Lécharny <
> elecharny@gmail.com>
> >>> wrote:
> >>>
> >>>> Le 04/08/2017 à 05:32, Dineth Chalitha Basnayaka a écrit :
> >>>>> Can you give what are the possible places in ldap server I can access
> >>>> that
> >>>>> message.
> >>>> http://www.catb.org/esr/faqs/smart-questions.html#explicit
> >>>>
> >>>> In other word, ApacheDS is a 200 000 lines of code project. Im not
> going
> >>>> to go throught it to show you how to get the information you need, it
> >>>> would simply take me days. Either you tell me where in the code you
> want
> >>>> to access LDAPMessage, or you are totally on your own.
> >>>>
> >>>>
> >>>> Thanks.
> >>>>
> >> --
> >> Emmanuel Lecharny
> >>
> >> Symas.com
> >> directory.apache.org
> >>
> >>
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>
Re: Access LDAPmessage
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 19/12/2017 à 11:02, Dineth Chalitha Basnayaka a écrit :
> Hi Emmanuel,
>
> After a long time. I hope you can remember me. :-)
The mailing list does :-)
> Your previous answer was very helpful for continuing my project and
> achieved some milestone. Here I got the user data from LDAP entry and store
> those things into different types of databases like MySQL. Now I need to
> build a message response.When I'm going to do that I got the problem "get a
> message ID at the interceptor level".
You can't.
Here, I tried using
> context(eg-addContext) parameter to get the message ID. But I could not get
> it. I would like to know am I missed something or are there have any
> limitations to get the message ID at the interceptor level.
The MessageId is already stored in the response that will be sent back
to the caller.
In the DefaultCoreSession, for each operation (AddRequest for instance),
we create a dedicated context :
public void add( AddRequest addRequest, LogChange log ) throws
LdapException
{
AddOperationContext addContext = new AddOperationContext( this,
addRequest );
...
Then we propagate this context to the server, which does what it has to do :
OperationManager operationManager =
directoryService.getOperationManager();
try
{
operationManager.add( addContext );
}
At this point, we can start thinking about returning a response, which
will contain some extra information if we've got an error (and this is
done in the caller, ie the AddRequestHandler class) :
public void handle( LdapSession session, AddRequest req )
{
LdapResult result = req.getResultResponse().getLdapResult();
try
{
// Call the underlying layer to inject the new entry
CoreSession coreSession = session.getCoreSession();
...
This is where we call the server :
coreSession.add( req );
Now deal with the response :
// If success, here now, otherwise, we would have an exception.
result.setResultCode( ResultCodeEnum.SUCCESS );
// Write the AddResponse message
session.getIoSession().write( req.getResultResponse() );
And we are done : the messageID is automatically stored in the response,
because the response is alrrady present and associaetd with the request
(actally, it has been created when the request has been received).
Note that the messageID for the response is the one stored in the request.
In any case, you never need to take care of that, just make it so the
response is properly returning the way it currently is.
--
Emmanuel Lecharny
Symas.com
directory.apache.org