On 14/11/2019 07:30, Prashanth Madduri wrote:
Hi Team,
We have ApacheDS 2.0.0 version installed on operating system Windows
Server 2012R2. We have use case where the client should retrieve all
the entries available in LDAP server. The entries can be of any size
like millions. We are using LDAPJS node module paging
(http://ldapjs.org/client.html#paging) to retrieve the entries with
each page size has 100. As per our observation the pagination is
working within the same connection from client to LDAP server with the
Buffer returned from previous paged results using PageResultControl
but the same Buffer is failing when the connection is different/new
and giving "error: Invalid cookie for this PagedSearch request" error.
Plain normal. The PagingSerachResult control is a per connection
control, it can't be shared.
We don't have any issue for pagination if we have single client
application running and communicating with LDAP server. In our case we
are following micro-service architecture and our client application
will run in multiple instances and user next page request may goes to
new instance with the Buffer captured from previous results which
results failure with invalid cookie error.
We have below two questions:
1. Is there any way to handle the pagination with multiple connections
to server with the Buffer string provided from previous page results?
No. This is not allowed by the RFC (https://tools.ietf.org/html/rfc2696)
2. How the LDAP server is identifying the connections? This is
considering we are facing invalid cookie issue for the same client
server communication with the captured cookie.
A LDAP session is a connection on which a BIND has been issued. It's
valid until a UNBIND is done, or until another BIND request is received.
Note that you can have anonymous LDAP sessions, if no BIND request is
emitted, and if the server accepts such sessions.
Once the connection is created, a LDAP session is always created.
Technically, a connection is an established socket connection between a
client and a server, but you don't have to care about that.
For what it worth, in your case, you should create a pool of
connections, associated with a generic user, and reuse this connection
with its PagedSearchControl cookie to be able to get what you want
across various clients. The drawback is that you will lose the identity
of the associated LDAP Session (ie, you are using a global user to do
your search). Now, if this kind of search is done by various clients,
you are on your own: there is no way to send back a LDSAP session cookie
to another LDAP session.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
