With the update to 17.0.3 the user_ldap app floods the log with
[user_ldap] Error: Could not autodetect the UUID attribute
raw:
{"reqId":"enyG4OzyuY0jSGxQDRpO","level":3,"time":"2020-02-12T07:45:25+00:00","remoteAddr":"","user":"--","app":"user_ldap","method":"","url":"--","message":"Could not autodetect the UUID attribute","userAgent":"--","version":"17.0.3.1","id":"5e43ad16295d2"}
See also https://help.nextcloud.com/t/nc-17-0-3-could-not-autodetect-the-uuid-attribute/70350
I stumbled over this today, too.
For one, you can ignore it. This should be reduced to debug indeed, and normally it does not really matter / is a false positive.
@bnavigator #19549 should fix it, do you mind testing?
Can confirm, with the pr patch applied to 17.0.3 (user_ldap version 1.7.0) the error log entries do not occur anymore.
For one, you can ignore it. This should be reduced to debug indeed, and normally it does not really matter / is a false positive.
@blizzz Sorry for the noise, but can you explain why this failure does not matter? Which UUID attribute is being used if the autodetect function cannot detect one? I would suspect that without knowing the UUID attribute, the LDAP integration cannot map users at all?
The provided DN that is being used to resolve the UUID attribute stems from an LDAP search operation, but it might simply not satisfy the filter. For instance when it resulted from fetching group members. The UUID attribute is present for either one or all records, so if there was a real problem, you would have noticed it long before, when no user is being shown.
Another hint: you can specify the correct attribute yourself in expert settings, then the detection won't be necessary at all.
Many thanks for the clarifications!
you can specify the correct attribute yourself in expert settings
Indeed, this was the primary intent for my question: should I override it, to avoid problems with the autodetection. Now solved - I don't need to, but it could be good practice, just to avoid some microseconds of autodetection time per request. Thanks again.