You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I checked for similar issues, but could not find any. I also checked the closed issues. I could not contribute additional information to any existing issue.
I will take the time to fill in all the required fields. I know that the bug report may be dismissed otherwise due to lack of information.
Describe the bug
The client in version 4.0 seems to change the way of authentication of previous clients.
In our current installation the user logs in via email "email@mydomain.com" and accesses his folder with an internal id.
In the LDAP configuration we use (email=%uid) and internally owncloud used a different UID than the email (which it gets from LDAP).
Up to version 3.2.1 everything worked correctly.
Version 4.0 works incorrectly. The first time it connects correctly using the email, then it gets the internal uid and the rest of authentications uses that internal uid to authenticate.
That is, it does NOT use the %uid provided by the user (in our case email@mydomain.com) except the first time.
The client must use the login provided by the user and not the one obtained later.
We have had to modify the ldap query so that it is "(|(email=%uid)(internaluid=%uid))"" so that it can log in and not be in an infinite loop asking for the password for a uid that is not the one provided by the user (it should be the email).
Tested on '10.12.1.3 and 10.0.7.2 server with 4.0.0.10896 client on linux,windows and macos.
Expected behavior
Client should use the same %uid used by the user in the configuration window.
Steps to reproduce the issue
Create a new account
Try to connect
Screenshots
Logs
{"reqId":"04e80675-feb3-486d-a3c6-e0eb1502abde",
"level":0,"time":"2023-06-12T13:57:18+02:00",
"remoteAddr":"***.***.***.***",
"user":"--",
"app":"webdav",
"method":"PROPFIND",
"url":"/remote.php/dav/files/*****/",
"message":"Exception: HTTP/1.1 401 No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured: {"Exception":"Sabre\DAV\Exception\NotAuthenticated","Message":"No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured","Code":0,"Trace":"#0 /var/www/html/owncloud-10.12.1/lib/composer/sabre/event/lib/WildcardEmitterTrait.php(89): Sabre\DAV\Auth\Plugin->beforeMethod()
#1 /var/www/html/owncloud-10.12.1/lib/composer/sabre/dav/lib/DAV/Server.php(456): Sabre\DAV\Server->emit()
#2 /var/www/html/owncloud-10.12.1/lib/composer/sabre/dav/lib/DAV/Server.php(253): Sabre\DAV\Server->invokeMethod()
#3 /var/www/html/owncloud-10.12.1/apps/dav/lib/Server.php(348): Sabre\DAV\Server->start()
#4 /var/www/html/owncloud-10.12.1/apps/dav/appinfo/v2/remote.php(31): OCA\DAV\Server->exec()
#5 /var/www/html/owncloud-10.12.1/remote.php(165): require_once('/var/www/html/o...')
#6 {main}","File":"/var/www/html/owncloud-10.12.1/lib/composer/sabre/dav/lib/DAV/Auth/Plugin.php","Line":152}"}
Client version number
ownCloud 4.0.0.10896 [74fef3](https://github.com/owncloud/client/commit/74fef3a70c2c7bb95598574e31d30bcade9a4eb6)
Libraries Qt 5.15.8, OpenSSL 1.1.1t 7 Feb 2023
Using virtual files plugin: wincfapi
windows-10.0.22621
Desktop environment (Linux only)
No response
Client package version and origin (Linux only)
No response
Installation path (Windows only)
No response
Server information
Tested on '10.12.1.3 and 10.0.7.2 servers with LDAP
Additional context
No response
The text was updated successfully, but these errors were encountered:
Pre-submission Checks
Describe the bug
The client in version 4.0 seems to change the way of authentication of previous clients.
In our current installation the user logs in via email "email@mydomain.com" and accesses his folder with an internal id.
In the LDAP configuration we use (email=%uid) and internally owncloud used a different UID than the email (which it gets from LDAP).
Up to version 3.2.1 everything worked correctly.
Version 4.0 works incorrectly. The first time it connects correctly using the email, then it gets the internal uid and the rest of authentications uses that internal uid to authenticate.
That is, it does NOT use the %uid provided by the user (in our case email@mydomain.com) except the first time.
The client must use the login provided by the user and not the one obtained later.
We have had to modify the ldap query so that it is "(|(email=%uid)(internaluid=%uid))"" so that it can log in and not be in an infinite loop asking for the password for a uid that is not the one provided by the user (it should be the email).
Tested on '10.12.1.3 and 10.0.7.2 server with 4.0.0.10896 client on linux,windows and macos.
Expected behavior
Client should use the same %uid used by the user in the configuration window.
Steps to reproduce the issue
Screenshots
Logs
Client version number
Desktop environment (Linux only)
No response
Client package version and origin (Linux only)
No response
Installation path (Windows only)
No response
Server information
Tested on '10.12.1.3 and 10.0.7.2 servers with LDAP
Additional context
No response
The text was updated successfully, but these errors were encountered: