Ability to leave the connection open

[halostatue]

Originally submitted on RubyForge by James Hewitt as #23425 on 2009-01-03:

I'd like to be able to leave an LDAP connection open.

I know the library doesn't want me to, but I would like to be able to decide what to do with my own network connections.

In some cases, leaving the ldap connection open makes writing my application a lot easier, for example, where I want to only use one ldap connection for each request to a rails app, but don't want to have to wrap the whole request in an LDAP.open. Or even to have an ldap connection pool, as you would a mysql connection pool.

I would suggest:

1. Altering LDAP.open to open the connection and leave it open if a block is not given.
2. Adding a close method to close connections.

[halostatue]

Comment by Austin Ziegler on 2010-09-25:

This is not currently planned and I'm not sure it's generally a good idea based on my understanding of how LDAP is supposed to work.

I understand your request for a connection pool, but either doing that or just keeping the connection open introduces a lot of extra code when we do operations to ensure that the currently opened connection is still valid.

Can you make a stronger case for this feature?

[grawity]

I don't see how this is part of "how LDAP is supposed to work", or how it is different from, let's say, MySQL, which does often use a single connection for an entire script (which isn't necessarily running for a long time, but might be simply too complex to be wrapped inside a @ldap.open do ...).

But in my experience, losing the connection in the middle of a script (be it SQL or LDAP) is such a rare occurence that I personally would be fine with the library just throwing an exception when that happens, and letting my code reconnect and re-authenticate.

One use case that comes to mind is LDAP servers that require more complex authentication mechanisms, such as SASL GSSAPI. In this case, opening a connection and reauthenticating for every operation can cause a considerable hit on performance. This is, in fact, what is happening with a script I'm trying to write at this moment...

[llaurent]

I can't agree more with grawity.
There are use cases blocks can't solve...

[mtodd]

This will likely be easier to do as we work on issues around Net::LDAP#open being discussed in #129, #133, #136, and #138. #135 is also somewhat related.

[sonOfRa]

Sorry to be replying to such an old issue, but I stumbled across this issue while considering a rewrite of some of our LDAP management tools:

https://gist.github.com/sonOfRa/9f2474cf5cd3586d3061f7bf0669c9e7

tl;dr: In order to have accountability, LDAP actions are performed by the user who is logged in, and not by some maintenance user. Currently, we cache the password in memory so the user doesn't have to re-enter it for every LDAP action. It would be great to have connection reuse so this password storing can be eliminated.

[grawity]

@sonOfRa:

LDAP actions are performed by the user who is logged in, and not by some maintenance user.

You could log in using the maintenance user's credentials but with the human operator's authzid, no?

[sonOfRa]

I have not considered this actually, thanks for the suggestion.

Based on my quick readup on how authzid works, I can see these problems:

1. Now I need to store the password for such a management user on disk persistently somehow
2. The management user needs to be able to "become" any user, even actual administrative users, so that user has (transitively) full write rights to the entire tree.

I'm not sure whether this is actually better than the old way, because in the old way, I only store passwords in memory for the duration of the user's session, now I'd store a single password with (essentially) full write access on disk. Of course, I may have misunderstood the authzid concept completely, in which case these points probably don't apply.