User gets error after few seconds because of LDAP error
Please verify that this bug has NOT been raised before.
- [x] I checked and didn't find a similar issue
Describe the bug*
When a new user logs in via LDAP, and I assign the correct group, then, even after relogin (and browser cache clearance etc). I get the following error:
Steps to Reproduce
- New user logs in using LDAP
- Assign correct group
- Relogin and clear browser
- go to parts overview and wait a few secondss
- Parts disappear and error appears.
Expected behaviour
No errors
Deployment Method
Docker
Version Information
InvenTree-Version: 1.1.1 Django Version: 4.2.25 Commit Hash: d3a58ea Commit Date: 2025-11-03 Commit Branch: null Database: django.db.backends.postgresql Debug-Mode: True Deployed using Docker: True Platform: Linux-6.1.0-40-amd64-x86_64-with-glibc2.41 Installer: DOC Active plugins: [{"name":"InvenTreeBarcode","slug":"inventreebarcode","version":"2.1.0"},{"name":"BOM Exporter","slug":"bom-exporter","version":"1.1.0"},{"name":"InvenTree Exporter","slug":"inventree-exporter","version":"1.0.0"},{"name":"Part Parameter Exporter","slug":"parameter-exporter","version":"1.0.0"},{"name":"InvenTreeEmailNotifications","slug":"inventree-email-notification","version":"1.0.0"},{"name":"InvenTreeUINotifications","slug":"inventree-ui-notification","version":"1.0.0"},{"name":"InvenTreeCurrencyExchange","slug":"inventreecurrencyexchange","version":"1.0.0"},{"name":"InvenTreeMachines","slug":"inventree-machines","version":"1.0.0"},{"name":"InvenTreeLabel","slug":"inventreelabel","version":"1.1.0"},{"name":"InvenTreeLabelMachine","slug":"inventreelabelmachine","version":"1.0.0"},{"name":"Altium BOM Importer","slug":"altium-bom-importer","version":"0.2.0"},{"name":"Altium Connector","slug":"altium-connector","version":"0.3.0"},{"name":"Custom BOM Exporter","slug":"custom_bom_exporter","version":"0.2.2"},{"name":"IPNGenerator","slug":"ipngen","version":"0.2"},{"name":"SolidWorks BOM Importer","slug":"solidworks-bom-importer","version":"0.2.0"},{"name":"Tree View","slug":"tree-view","version":"0.1.1"}]
Try to reproduce on the demo site
I did not try to reproduce
Is the bug reproducible on the demo site?
Not reproducible
Relevant log output
Traceback (most recent call last):
File "/root/.local/lib/python3.11/site-packages/rest_framework/views.py", line 512, in dispatch
response = handler(request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/rest_framework/views.py", line 526, in options
data = self.metadata_class().determine_metadata(request, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/inventree/src/backend/InvenTree/InvenTree/metadata.py", line 130, in determine_metadata
result = check_user_permission(user, self.model, permission) or (
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/inventree/src/backend/InvenTree/users/permissions.py", line 165, in check_user_permission
result = user.has_perm(permission_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/django/contrib/auth/models.py", line 311, in has_perm
return _user_has_perm(self, perm, obj)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/django/contrib/auth/models.py", line 220, in _user_has_perm
if backend.has_perm(user, perm, obj):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/django_auth_ldap/backend.py", line 192, in has_perm
return perm in self.get_all_permissions(user, obj)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/django_auth_ldap/backend.py", line 202, in get_all_permissions
return self.get_group_permissions(user, obj)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/django_auth_ldap/backend.py", line 209, in get_group_permissions
permissions = user.ldap_user.get_group_permissions()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/django_auth_ldap/backend.py", line 405, in get_group_permissions
self._load_group_permissions()
File "/root/.local/lib/python3.11/site-packages/django_auth_ldap/backend.py", line 841, in _load_group_permissions
group_names = self._get_groups().get_group_names()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/django_auth_ldap/backend.py", line 949, in get_group_names
group_infos = self._get_group_infos()
^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/django_auth_ldap/backend.py", line 996, in _get_group_infos
self._group_infos = self._group_type.user_groups(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/django_auth_ldap/config.py", line 536, in user_groups
return search.execute(ldap_user.connection)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/django_auth_ldap/config.py", line 204, in execute
results = connection.search_s(
^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/ldap/ldapobject.py", line 631, in search_s
return self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout=self.timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/ldap/ldapobject.py", line 624, in search_ext_s
msgid = self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/ldap/ldapobject.py", line 614, in search_ext
return self._ldap_call(
^^^^^^^^^^^^^^^^
File "/root/.local/lib/python3.11/site-packages/ldap/ldapobject.py", line 128, in _ldap_call
result = func(*args,**kwargs)
^^^^^^^^^^^^^^^^^^^^
TypeError: search_ext() argument 1 must be str, not None
@wolflu05 @jacobfelknor any insight on that error? Not really using ldap anywhere anymore
Sorry, no im also not using ldap anymore in my deployment.
I use LDAP, but I also know LDAP environments can be very different from each other and I personally can only test against the environment I'm in, which I don't administer.
My (redacted) LDAP configuration looks like
# LDAP Support
INVENTREE_LDAP_ENABLED=True
INVENTREE_LDAP_DEBUG=True
INVENTREE_LDAP_SERVER_URI="ldap://EXAMPLE.LOCAL:389"
INVENTREE_LDAP_START_TLS=False
INVENTREE_LDAP_AUTH_SEARCH_BASE="ou=Example Users,ou=Example,dc=EXAMPLE,dc=LOCAL"
INVENTREE_LDAP_BIND_DN="CN=EX LDAP,OU=Example,OU=Example Users,OU=Example,DC=EXAMPLE,DC=LOCAL"
INVENTREE_LDAP_BIND_PASSWORD="********"
INVENTREE_LDAP_SEARCH_BASE_DN="ou=Example Users,ou=Example,dc=EXAMPLE,dc=LOCAL"
INVENTREE_LDAP_SEARCH_FILTER_STR="(&(objectCategory=user)(sAMAccountName=%(user)s))"
# AUTH_LDAP_USER_ATTR_MAP="{'name': 'displayName', 'username': 'sAMAccountName', 'first_name': 'givenName', 'last_name': 'sn', 'email': 'mail', 'extension': 'telephoneNumber'}"
INVENTREE_LDAP_MIRROR_GROUPS=True
INVENTREE_LDAP_GROUP_SEARCH="OU=Example Groups,OU=Example Groups,OU=Example,DC=EXAMPLE,DC=LOCAL"
INVENTREE_LDAP_GROUP_OBJECT_CLASS="group"
INVENTREE_LDAP_GROUP_TYPE_CLASS="NestedMemberDNGroupType"
INVENTREE_LDAP_GROUP_TYPE_CLASS_ARGS="member"
INVENTREE_LDAP_GROUP_TYPE_CLASS_KWARGS='{"name_attr": "cn"}'
@bvweerd, is yours significantly different? I haven't experienced this issue.
It is significantly smaller:
INVENTREE_LDAP_ENABLED=true
INVENTREE_LDAP_SERVER_URI=ldaps://ldap.example.com:636
INVENTREE_LDAP_BIND_DN=uid=ldapbind,ou=Users,o=*********,dc=example,dc=com
INVENTREE_LDAP_BIND_PASSWORD=***********
INVENTREE_LDAP_SEARCH_BASE_DN=ou=Users,o=**********,dc=example,dc=com
INVENTREE_AUTH_LDAP_FIND_GROUP_PERMS=False
INVENTREE_LDAP_USER_SEARCH_FILTER=(uid=%(user)s)
INVENTREE_LDAP_START_TLS=false
INVENTREE_LDAP_ACTIVE_DIRECTORY=false
INVENTREE_LDAP_REQUIRE_GROUP=false
INVENTREE_LDAP_MIRROR_GROUPS=false
INVENTREE_LDAP_DEBUG=true
#8308 lead me to a work around. I added
INVENTREE_LDAP_GROUP_SEARCH=
which still causes an error in the logs, but at least the ui doesn't deny access anymore. Error in logs:
Caught LDAPError loading group permissions: NO_SUCH_OBJECT({'msgtype': 101, 'msgid': 2, 'result': 32, 'desc': 'No such object', 'ctrls': []})
Not sure that is a great solution; can you work that way?
@SchrodingersGat @wolflu05 long term we really need to consider getting LDAP either unit tested or moved from core into a plugin
It works for my users now, no visible errors, just spamming in the error logs.
I would be fine with it, if you want to move this to a plugin.
Thanks for the headsup. ldap is a necessity. if I were willing to forgo it, then homebox is known to work out-of-the-box.
Thanks for the headsup. ldap is a necessity. if I were willing to forgo it, then homebox is known to work out-of-the-box.
Reading the last few issues you submitted today I welcome you using any other solution instead of wasting our time by not reading the docs and filing low-effort issues