-
Notifications
You must be signed in to change notification settings - Fork 38
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.
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
get_object() throws a KeyError exception when user not found #86
Comments
I had to go through LDAP3 documentation thoroughly to understand what's going on. So... the biggest limitation of this module is that it's built around RAW response object, rather than ENTRIES. For example, here's a slightly modified code that does not suffer from the same problem
Even better if it was just returning an entry object as it's so much more powerful. Few examples:
Anyway, by playing with LDAP3 I figured out that this plugin is TOO heavy for my needs. Therefore I will move away to use pure LDAP3 instead. Leaving this issue open for future potential improvements. Consider using |
I think this is most likely a real bug; I've added it to the 1.0 milestone. |
This issue only happens whenever I want to user
get_user_info_for_username()
and search applies to Base DN only (i.e. User DN is None). The way our AD is structured is there are following elements at its rootall user and group OUs/CNs are here
Unfortunately, if I use
get_user_info_for_username(username)
it throws the following error:I had to modify source code of
get_object()
as per below to get some debug data:It returned the following
So, even though user does not exist under DC=domain,DC=com, LDAP plugin searches through parallel structures and returns a list as seen above. Because
get_object()
only checks forlen(connection.response) > 0
, this results into condition as if user was found. Last line in the code then raisesKeyError
exception because first item (in fact all those in the response) has no 'attributes' key in its list.Would you be so kind to advise if I have to apply an alternative approach? At the moment I ended up capturing this exception in my code, but it doesn't seem CLEAN. This exception is due to Flask-LDAP3-Login not processing the data properly, imho.
The text was updated successfully, but these errors were encountered: