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 <[email protected]>
Signed-off-by: Arthur Schiwon <[email protected]>
blizzz
added
bug
3. to review
blizzz
requested review from
GitHubUser4234,
MorrisJobke,
juliusknorr,
rullzer,
violoncelloCH and
weeman1337
@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? |
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 <[email protected]>
|
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, |
|
Just wanted to let you know, that we at Cloudron have successfully tested this against 14.0.4 |
|
Pretty please!? |
Signed-off-by: Arthur Schiwon <[email protected]>
|
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? |
|
@nebulade thanks for testing and reporting back! |
|
/backport to stable15 |
|
/backport to stable14 |
|
CI failures unrelated:
|
juliusknorr
added
the
4. to release
|
backport to stable15 in #13119 |
|
The backport to stable14 failed. Please do this backport manually. |
|
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 |
|
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.