fix(LDAP): drop hard base checks for now

[blizzz]

• Resolves: [Bug]: Nextcloud 32 breaks LDAP for some overlay directory schemas #55613

Summary

The migration path is hard and unexpected. We can follow-up with a soft setup check instead for a while, but needs to be discussed.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

[blizzz]

/backport to stable32

[hamza221]

the private function checkBasesAreValid is still there and not being used anywhere else

[blizzz]

the private function checkBasesAreValid is still there and not being used anywhere else

might still be useful, going to check with @come-nc next week.

[come-nc]

@blizzz So I checked the code a bit more and ldapBase is actually almost never used, apart from counting objects to test its value, and as default value for the other bases in the wizard. So it could even be removed and replaced by a test field.

I guess it’s fine to simply revert the check for now as bad values in this field are not important in the end. We should just make sure it’s never used as the actual base of the LDAP in the future.

Ideally we should inverstigate why a failing check caused so much trouble, especially the memory limit issues are concerning. But also I think most people failed to understand what the error meant and that the base field is actually multi-valued.

[blizzz]

@blizzz So I checked the code a bit more and ldapBase is actually almost never used, apart from counting objects to test its value, and as default value for the other bases in the wizard. So it could even be removed and replaced by a test field.

I guess it’s fine to simply revert the check for now as bad values in this field are not important in the end. We should just make sure it’s never used as the actual base of the LDAP in the future.

👍 Yeah, as said, it is part of the cozy-easy-setup for non-LDAP-knowledgable people and basically copied over as user and group tree quite soonish. I don't think it was ever used for anything else?

Ideally we should inverstigate why a failing check caused so much trouble, especially the memory limit issues are concerning. But also I think most people failed to understand what the error meant and that the base field is actually multi-valued.

Though I was curious I did not have time too look into what the check was doing. Gut feeling said it looked like recursing endlessly, did not really look into it though. But struck me odd.