Add a way to construct django username from the _LDAPUser object #154
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a backward compatible change to supercede the ldap_to_django_username hook with get_django_username_from_ldap_user which takes _LDAPUser instance as argument and returns the django username. By default it just calls ldap_to_django_username(ldap_user._username) to be compatible with code that's based on older versions of this library and expects ldap_to_django_username to be the function translating from ldap username to django. New code can now in their LDAPBackend subclasses override get_django_username_from_ldap_user with potentially more sophisticated logic that constructs the django username from information available in the _LDAPUser object - typically from the attributes.
timabbott
pushed a commit
to zulip/zulip
that referenced
this pull request
Oct 22, 2019
Fixes #11878 Instead of a confusing mix of django_auth_backed applying ldap_to_django_username in its internals for one part of the translation, and then custom logic for grabbing it from the email attribute of the ldapuser in ZulipLDAPAuthBackend.get_or_build_user for the second part of the translation, we put all the logic in a single function user_email_from_ldapuser which will be used by get_or_build of both ZulipLDAPUserPopulator and ZulipLDAPAuthBackend. This, building on the previous commits with the email search feature, fixes the ldap sync bug from issue #11878. If we can get upstream django-auth-ldap to merge django-auth-ldap/django-auth-ldap#154, we'll be able to go back to using the version of ldap_to_django_username that accepts a _LDAPUser object.
evo42
pushed a commit
to evo42/zulip
that referenced
this pull request
Oct 30, 2019
Fixes zulip#11878 Instead of a confusing mix of django_auth_backed applying ldap_to_django_username in its internals for one part of the translation, and then custom logic for grabbing it from the email attribute of the ldapuser in ZulipLDAPAuthBackend.get_or_build_user for the second part of the translation, we put all the logic in a single function user_email_from_ldapuser which will be used by get_or_build of both ZulipLDAPUserPopulator and ZulipLDAPAuthBackend. This, building on the previous commits with the email search feature, fixes the ldap sync bug from issue zulip#11878. If we can get upstream django-auth-ldap to merge django-auth-ldap/django-auth-ldap#154, we'll be able to go back to using the version of ldap_to_django_username that accepts a _LDAPUser object.
YashRE42
pushed a commit
to YashRE42/zulip
that referenced
this pull request
Dec 12, 2019
Fixes zulip#11878 Instead of a confusing mix of django_auth_backed applying ldap_to_django_username in its internals for one part of the translation, and then custom logic for grabbing it from the email attribute of the ldapuser in ZulipLDAPAuthBackend.get_or_build_user for the second part of the translation, we put all the logic in a single function user_email_from_ldapuser which will be used by get_or_build of both ZulipLDAPUserPopulator and ZulipLDAPAuthBackend. This, building on the previous commits with the email search feature, fixes the ldap sync bug from issue zulip#11878. If we can get upstream django-auth-ldap to merge django-auth-ldap/django-auth-ldap#154, we'll be able to go back to using the version of ldap_to_django_username that accepts a _LDAPUser object.
|
AFAICT, there must be a symmetry between django-auth-ldap makes the assumption that a Django username can be transformed to an Breaking this assumption has implications in the library, for example, using the Can you explain the motivation for this change? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It seems like a fairly common scenario for an application to want to have the django username
constructed from the attributes loaded from ldap, rather than directly the ldap username as is currently allowed by the
ldap_to_django_usernamehook.This doesn't include updating the docs - but I'll add that after review of the code, once the final form of how this functionality should be structured is known.
This is a backward compatible change to supercede the
ldap_to_django_username hook with get_django_username_from_ldap_user
which takes _LDAPUser instance as argument and returns the django
username.
By default it just calls ldap_to_django_username(ldap_user._username) to
be compatible with code that's based on older versions of this library
and expects ldap_to_django_username to be the function translating from
ldap username to django.
New code can now in their LDAPBackend subclasses override
get_django_username_from_ldap_user with potentially more sophisticated
logic that constructs the django username from information available
in the _LDAPUser object - typically from the attributes.