Skip to content
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

Failed Login: Client 4.0 change value of %uid #10930

Closed
2 tasks done
pollopolea opened this issue Jun 15, 2023 · 1 comment
Closed
2 tasks done

Failed Login: Client 4.0 change value of %uid #10930

pollopolea opened this issue Jun 15, 2023 · 1 comment
Labels

Comments

@pollopolea
Copy link

pollopolea commented Jun 15, 2023

Pre-submission Checks

  • 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

  1. Create a new account
  2. Try to connect

Screenshots

2
3
1

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

@TheOneRing
Copy link
Member

Duplicate of #10856
Fixed in 4.1

@TheOneRing TheOneRing closed this as not planned Won't fix, can't repro, duplicate, stale Jun 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants