On Thu, Nov 27, 2014 at 4:51 AM, Michael Ströder <[email protected]> wrote:
> Qian Li wrote: > > On Wed, Nov 26, 2014 at 5:30 PM, Michael Ströder <[email protected]> > > wrote: > > > >> Qian Li wrote: > >>> Recently, I tried to write a ldap client to do ldap search > >> asynchronously, > >>> but failed to perform search operation after a successful async sasl > >>> (digest-md5) bind. > >> > >> What's your use-case for having async bind operation? > >> > >> Note that the bind operation is somewhat special because it establishs a > >> security context/association. > > > > The ldap client is a daemon which accepts arbitrary request > > from outside > > What kind of requests? There are IPCs from other processes and the ldap client is only single thread. > > and periodically retrieves all users/groups from ldap server. > > A simple search? Security requirements regarding passwords? > Security requirements only regarding bound identity's password. If simple bind is used, the identity's password will be plain text in the search request. > > > For sync bind, the client needs to wait for bind to complete, which could > > make outside request not be responded for a time . > > It would be better to support async bind in the client. > > That does not make sense. > > Again: > The bind operation is somewhat special because it establishs a security > context/association. Note that the following LDAP requests are authorized > based on the bound identity. > > I don't know what's your exact use-case. But if you're cautious about > performance you should open a connection pool of persistent connections and > always bind *once* during connection lifetime. > Yes, persistent connections pool is another solution. The search operation works in both async simple bind and sync SASL/DIGEST-MD5 bind, but doesn't work in async SASL/DIGEST-MD5 bind. This confuses me...
