LDAP error in Nextcloud 13 beta1 #7400
Comments
blizzz
added
0. Needs triage
|
If it's worth noting, I upgraded another nextcloud server and I get the same error |
|
@Emi94 AD I guess? Would be great if you could provide a full report according to the template https://raw.githubusercontent.com/nextcloud/server/master/issue_template.md |
Steps to reproduce
Expected behaviourNo Error should be thrown Actual behaviourThis error is thrown multiple times when an LDAP user does any action:
Server configurationOperating system: Ubuntu 16.04 Signing statusApp listNextcloud configuration: Config reportAre you using external storage, if yes which one: no Are you using encryption: no Are you using an external user-backend, if yes which one: LDAP(Samba) LDAP configuration (delete this part if not used)LDAP configLogsNextcloud log (data/nextcloud.log)Nextcloud log |
Steps to reproduce
Expected behaviourClean Logfile Actual behaviourEvery action of the AD-User creates an error: Server configurationOperating system: Ubuntu 16.04 Signing statusList of activated apps: App listEnabled:
Nextcloud configuration: Config reportAre you using external storage, if yes which one: LDAP configuration (delete this part if not used)LDAP config+-------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Client configurationBrowser: Chrome Operating system: Windows 10 LogsNextcloud log (data/nextcloud.log)Nextcloud log{"reqId":"1gwySOA38yWTBqCesb6j","level":3,"time":"2017-12-07T12:23:36+00:00","remoteAddr":"IP_Adress_Changed","user":"001D7D89-485F-4970-8C2A-6B7F82C485DD","app":"PHP","method":"PROPFIND","url":"\/remote.php\/dav\/files\/001D7D89-485F-4970-8C2A-6B7F82C485DD\/","message":"bin2hex() expects parameter 1 to be string, array given at \/var\/www\/nextcloud\/apps\/user_ldap\/lib\/Access.php#1638","userAgent":"Mozilla\/5.0 (Windows) mirall\/2.3.3 (build 1) (Nextcloud)","version":"13.0.0.6"} |
|
I can also reproduce. Differences to reports above:
My ldap server is OpenLDAP's slapd. |
|
The function in which the error occurs |
MorrisJobke
added
bug
and removed
0. Needs triage
|
@blizzz: Also happens here and the |
|
a quick thing you may try: diff --git a/apps/user_ldap/lib/Access.php b/apps/user_ldap/lib/Access.php
index 95710cd37f..27fda38a73 100644
--- a/apps/user_ldap/lib/Access.php
+++ b/apps/user_ldap/lib/Access.php
@@ -1253,11 +1253,13 @@ class Access extends LDAPUtility implements IUserTools {
unset($item[$key]['count']);
}
if($key !== 'dn') {
- $selection[$i][$key] = $this->resemblesDN($key) ?
- $this->helper->sanitizeDN($item[$key])
- : $key === 'objectguid' || $key === 'guid' ?
- $selection[$i][$key] = $this->convertObjectGUID2Str($item[$key])
- : $item[$key];
+ if($this->resemblesDN($key)) {
+ $selection[$i][$key] = $this->helper->sanitizeDN($item[$key]);
+ } else if($key === 'objectguid' || $key === 'guid') {
+ $selection[$i][$key] = [$this->convertObjectGUID2Str($item[$key][0])];
+ } else {
+ $selection[$i][$key] = $item[$key];
+ }
} else {
$selection[$i][$key] = [$this->helper->sanitizeDN($item[$key])];
}
essentially it makes it more readable. The function should not have been called in the first play, and I blame the short comparison version as cause, although i could not verify it. Errors will go away anyway since the the function is now provided with the actual value, too. |
|
Yes - the brackets are missing to have the two short forms being separated properly. |
|
Let me create a PR and check if it helps over here. |
|
yes, that's what i think but I could not see wrong behavior with 3v4l.org on any version |
|
Let me take care of this then. |
Seems to be like that: |
|
Fix is in #7479 and solved it for the instance I noticed it. |
I just upgraded to Nextcloud 13 beta1 (user_ldap version: 1.3.1) and this error appears over and over in the logs when an LDAP user does any action, even when clicking a button or reloading the page.
Everything seems to work fine for now, but even if this is a harmless error it fills the logs pretty quick with just one LDAP user logged in. With a few dozens of active users it will produce way more logs than wanted.
The text was updated successfully, but these errors were encountered: