Skip to content

Ability to leave the connection open #11

Open
@halostatue

Description

@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.

Activity

halostatue

halostatue commented on Jul 12, 2011

@halostatue
Author

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

grawity commented on May 28, 2012

@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

llaurent commented on Oct 28, 2013

@llaurent

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

mtodd

mtodd commented on Oct 19, 2014

@mtodd
Member

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

sonOfRa commented on Dec 14, 2016

@sonOfRa
Contributor

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

grawity commented on Dec 14, 2016

@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

sonOfRa commented on Dec 14, 2016

@sonOfRa
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @mtodd@halostatue@grawity@llaurent@sonOfRa

        Issue actions

          Ability to leave the connection open · Issue #11 · ruby-ldap/ruby-net-ldap