Uh oh!
There was an error while loading. Please reload this page.
fix exception on LDAP mapping during login - #12693
Conversation
during login they might be cached as non-existing and cause an Exception in the long run reduces some duplication, too Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
weeman1337
commented
Nov 29, 2018
@blizzz ha ha :) Then I would thank you for not blaming me ;) Is there any way I can test this? May it make sense to add some testing stuff here? |
blizzz
commented
Nov 29, 2018
Yes, have LDAP and memcache configured and do a first login with an unmapped user (→ one that does not appear in the Users page, best don't open it after configuring, just try the login directly). Before you will have the Exception happening exactly once (and the user would not be added to the system addressbook).
In general yes, just to increase the possible cases… It probably would be already caught if the LDAP integration tests would go with a memcache. But all the tests would need to be duplicated, or run twice somehow, with a different configuration. |
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
blizzz
commented
Dec 3, 2018
I think I enabled now Redis with the LDAP integration tests. This should suffice, as running it without memcache is not ideal or recommended |
Hello, |
nebulade
commented
Dec 13, 2018
Just wanted to let you know, that we at Cloudron have successfully tested this against 14.0.4 |
doodlemania2
commented
Dec 15, 2018
Pretty please!? |
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
blizzz
commented
Dec 17, 2018
Added clearing the cache on modification via API and CLI as well (Config wizard did it already), so the integration tests now run and succeed with Redis :) @weeman1337 OK with you? |
blizzz
commented
Dec 17, 2018
@nebulade thanks for testing and reporting back! |
blizzz
commented
Dec 17, 2018
/backport to stable15 |
blizzz
commented
Dec 17, 2018
/backport to stable14 |
juliusknorr
commented
Dec 17, 2018
CI failures unrelated:
|
backport to stable15 in #13119 |
The backport to stable14 failed. Please do this backport manually. |
danielbotting-mcr
commented
Jan 23, 2019
Hi, We've got a production environment Nextcloud 14 (docker) and a staging environment Nextcloud 15 (docker). I ran into the above issue when logging into the staging environment just after setting up LDAP app. I assumed I would see an update for the LDAP app that fixes this, but there is none. What do I need to resolve this issue in Nextcloud 14 and 15? Thanks |
blizzz
commented
Jan 23, 2019
The fix was deployed to 14.0.5 and 15.0.1. Compare your systems, if you run them at least, open a new bug report. Otherwise, update :) |
Blizz, Thanks for your prompt response, I am not running those versions. I shall update accordingly and open a bug report as applicable. Thanks :) |
fixes#11474
It seems the issue was introduced with c92d742, but I cannot (and will not :D) blame @weeman1337 for it. It is a side effect of how the LDAP Backend detects name collisions when creating a mapping, and caching.
A user object is fetched before matching, the yet non-existing user is found as non-existing and cached accordingly. The mapping follows later, is successful, but when a hook to announce this user is thrown a different listener wants to pull and fetch the brand new user object, but get's a null instead (and does not check for it).
The fix is essentially to cache the user after mapping. I removed some duplication as it is stupid to maintain and had a copy-paste issue in the past.