New LDAPProvider for user_ldap

[GitHubUser4234]

New LDAPProvider for user_ldap, please refer to #23855

[mention-bot]

By analyzing the blame information on this pull request, we identified @MorrisJobke, @blizzz and @LukasReschke to be potential reviewers

[GitHubUser4234]

When calling the user_ldap provider from a testing app, I'm currently running into a problem here, somehow the 'LDAP' backend is not in the loop, maybe because it is called before the 'LDAP' backend is registered? I have tried to uninstall and install the testing app again, but to no avail. Maybe something is wrong with this approach.

[blizzz]

Possible. Do you have the code of the testing app available? In general some types of apps are being loaded first and before others, including authentication. So, if your test app has this type set, you might want to remove it. As a guess into the blue.

[GitHubUser4234]

Not sure whether the usage of login names and internal user names is correct ☺️

[blizzz]

Nope. loginnames and usernames differ. What you have often with LDAP is that a login name looks like "a.user" or "a.user@server.tld" while the username is based on the UUID which may look like "AB1234C5-678D-9E01-2E34-F567GHI89012". Basically, you'd just remove if($userName = $this->backend->loginName2UserName($uid)){.

You should always operate with usernames, not login names as they don't necessarily need to be unique.

If your callee uses the loginname instead of the username: if the user is logged in, you'll get the username from \OC::$server->getUserSession()->getUser(). This returns null or an IUser object. In the first cast, it's an error and maybe you just want to throw an exception. In the normal case you'll get the username from getUID() of the IUser instance.

[blizzz]

Comments are inline, many taken out directly from my IDE ;) Smaller issues in general.

Three things remain, the first two low hanging fruits:

• in user_ldap's appinfo/install.php and appinfo/update.php a check should happen wether a provider is configured. If not, write the config accordingly. Probably best to have a method in Helper that you call from both scripts.
• In the LDAPProvider implementation actually check whether user_ldap is enabled, throw exception if not.
• lib/public/ILDAPAccess as stated here https://github.com/owncloud/core/pull/23992/files#r59937276 I believe originally I was thinking of not returning an instance of the Access class here, but the pure LDAP Connection resource. However we have some normalization and conversion stuff in place in Access that you would need to take care of yourself if you have just the LDAP resource. We should figure out what you want to be able to do. We could have a shortcut to get the LDAP connection resource from Access->getConnection()->getConnectionResource(). To have proper control, some methods for controlling paged search, for instance, make sense, as do DNasBaseParameter() or sanitizeDN() and probably others. This needs some more thought work unfortunately.

[GitHubUser4234]

Thanks a lot @blizzz for taking time to go through the mess 😅

Ok, I should have all that ready by tomorrow.

Meanwhile I have commited the testing app here. Currently the appinfo/app.php simply tries to initialize user_ldap's LDAPProvider and as mentioned above, it fails. The types in appinfo/info.xml are empty.

To understand what the app is going to do later, lib/hooks.php and lib/ldap.php could give an impression.

[blizzz]

intentionally?

[GitHubUser4234]

Thanks a lot @blizzz for your comments, they are implemented and committed. As discussed in IRC, the next step would be to implement unit tests to test all the public functions exposed by the LDAPProvider.

[ghost]

@GitHubUser4234

Thanks a lot for your contribution!
Contributions to the core repo require a signed contributors agreement http://owncloud.org/about/contributor-agreement/

Alternatively you can add a comment here where you state that this contribution is MIT licensed.

Some more details about out pull request workflow can be found here: http://owncloud.org/code-reviews-on-github/

[elie195]

Is this PR targeted for implementation in 9.2? I'm looking forward to implementing it in my app to map UUID to owncloud_name in order to support LDAP in instances where the internal UUID mapping is set to the default.

[PVince81]

@jvillafanez @DeepDiver1975 @owncloud/ldap

[jvillafanez]

The changes seem big enough to be considered almost a new app, because I don't think it was originally planned the app contains such changes.

• There are some refactor made there (sanitizeDN change the place in the PR) which is mixed with more changes. From my point of view, a bad idea since the change could have unexpected consecuences (some classes might be still calling to the old method). Such change should be isolated so we can verify that everything still works after the change.
• Modifying lib/private/Server.php is a no-go from my point of view. An app such LDAP musn't modify core stuff. 🚫
• Adding new interface to public library is also another no-go if it comes from another app such LDAP 🚫 . Core should provide generic interfaces for user and / or group handling, but never a specific interface for a specific service. It's fine is the LDAP app provide its own custom extension points so other apps hooks in there, but core shouldn't focus on LDAP.

[GitHubUser4234]

I switched to Nextcloud and I don't have the resources to maintain this PR in ownCloud. Sorry for any inconvenience caused.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.