Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Extract LDAPConnection as a separate class #249

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Extract LDAPConnection as a separate class #249

wants to merge 2 commits into from

Conversation

mateuszmandera
Copy link

This is for the needs of #150 (comment)

The first step of the refactoring is the first commit from #150 and in the second commit we refactor further to have LDAPConnection as a separate class, as suggested in the linked comment.

_LDAPUser gets some one-liner methods that just reference self._connection:

    def _bind(self):
        self._connection._bind()

    def _bind_as(self, bind_dn, bind_password, sticky=False):
        return self._connection._bind_as(bind_dn, bind_password, sticky)

    def _get_connection(self):
        return self._connection._get_connection()

    @property
    def connection(self):
        return self._connection.connection

This is in order to avoid changing the API - we probably don't want to break code relying on this module doing things like ldap_user.connection.

@francoisfreitag I'm not sure if this is the kind of design you wanted for LDAPConnection, so I'm happy to rework or tweak this as needed to get it mergeable but might need more pointers on what you have in mind for this class.

@mateuszmandera
Extract _LDAPConnectionMixIn class
b754cf5 
Having the connection-handling logic in a separate class allows more
extensibility.
@mateuszmandera
Extract LDAPConnection as a separate class
60d491c
@mateuszmandera mateuszmandera mentioned this pull request May 18, 2021
Open
@francoisfreitag
Copy link
Member

Thanks for the effort of splitting that chunk out. This is not the interface I hoped it would be.

The goal is to abstract away a manager for the lazy connection to the LDAP server. It should provide developers with a way to establish a connection to an LDAP server, use bind credentials in order to perform requests, and let them access the underlying connection object. I guess a LDAPConnectionWrapper could be an abstraction. It would ensure a connection to the LDAP server is established, offer access to the wrapped methods on the connection and perhaps manage the current binding, so that a bind request is issued when needed.

This change is putting the connection in another object but the _LDAPUser keeps managing the connection and accesses its protected properties.

@michaelsteigman
Copy link

Any further deliberations on this PR outside of this context?

I have run into the issue that #174 was intended to address after our organization moved to a different directory product. I'd like to see it addressed and would be happy to chip in.

@francoisfreitag
Copy link
Member

Hi @michaelsteigman,

Thanks for your interest. Unbinding the LDAP connection is fairly tricky, as the connection is currently managed by the _LDAPUser and bound to its lifecycle. The current behavior has nice properties, such as lazily connecting to the LDAP server, managing the credentials to use for authentication on the LDAP server (AUTH_LDAP_BIND_AS_AUTHENTICATING_USER), as well as allowing to defer the loading of attributes.

My initial take on how to limit the number of open connections / release them would be to pool connections (#174 (comment)), so that a working set of connections is maintained open, avoiding the cost of establishing new connections per HTTP request, as well as limiting the overall number of connections to the LDAP server.

This is not an easy change to implement. I started looking at it, but since my employer doesn’t need that feature for now, it’s been on my scarce personal time.

I’m happy to discuss the implementation, other designs are totally welcome, as long as they maintain the existing properties such as lazy connection and deferred loading of attributes and group membership.

@michaelsteigman
Copy link

michaelsteigman commented Sep 22, 2021 •
edited
Loading

Hi @francoisfreitag,

Thanks for the reply.

I was able to workaround the issue for a deadline this month but it sounds like an interesting challenge and a change that we'll need at some point.

I have some other priorities in the near terms but later in the fall, I will plan on looking into this in more detail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@mateuszmandera @francoisfreitag @michaelsteigman