Documentation for the new Ldap component

[xabbuh]

see symfony/symfony#14602

[weaverryan]

ping @csarrazi - this is one that I won't be able to right, without great trouble as I don't have any real LDAP experience. Are you able to add a document in the new 2 weeks?

[heiglandreas]

You know that there is https://packagist.org/packages/org_heigl/zendldapbundle ? Is there really the need for another LDAP-Implementation?

[csarrazi]

@heiglandreas The LdapBundle you are mentioning does basically nothing, and does not expose all LDAP options. The goal here is to have a working basic LDAP implementation, which is used by the SecurityBundle for authenticating a user against a LDAP server.

@weaverryan Could do, but first, I need to finalize symfony/symfony#15994, as the Ldap API will actually change a lot before the final release.

[heiglandreas]

@csarrazi I'm fully aware, that it does nothing except allowing a user to use Zend\Ldap inside symfony. As far as I know, there are some 3rd-party LDAP-Authentication bundles around but the last time I looked, there wasn't a full-featured LDAP-implementation. That's why I created that bundle.

So when I understand you right the new LDAP-component will have all the features necessary to authenticate a user but not necessary all features needed for full LDAP-usage?

[csarrazi]

In the long term, it will have all features for full LDAP usage.
However, for 2.8 / 3.0, only the binding and querying part will be ready. Updating, creating or removing LDAP entries will be for at least 3.1, depending on whether other people can help with this or not.

And provided we have users who actually want this feature.

[heiglandreas]

Just out of interest: Wouldn't it be easier to combine forces on one LDAP-AL and use that in different frameworks instead of splitting the contributors over different implementations? I'm maintaining Zend\Ldap and currently I'm the only one doing any actual work on it. And as it's a part that is not that widely used or understood splitting the contributor-base to such an AL is IMO removing power from every single project. Wouldn't having one AL implemented by the different frameworks be a more powerfull solution?

[csarrazi]

@heiglandreas This would have been great. However, the main reason why I did not use Zend\Ldap is because of the error handler's after effects, as mentioned on zendframework/zendframework#7497.

Indeed, during my tests, Zend\Ldap used to break the Symfony error handler, which is not registered back after Zend\StdLib\ErrorHandler::start(E_WARNING). This causes issues for error logging, which made it impossible to understand what happened under the hood when using the Zend\Ldap due to not having error logs anymore.

If these issues are fixed at a later time, I would be glad to provide a bridge for using Zend\Ldap in Symfony, instead of the Ldap component. The reason why the component provides an interface is to be able to hook (if needed) a userland PHP implementation of LDAP, or a third-party component, like Zend\Ldap.

For the record, at first this component wasn't even supposed to exist. The implementation is very simple, and is intended to be kept simple.

[heiglandreas]

Then let's join forces @csarrazi ;)

I'll dig into that issue with the error handler and check whether there is a way to get rid of the Zend\StdLib\ErrorHandler for Zend\Ldap.

Please don't get me wrong: Even though I'm maintaining Zend\Ldap I do not think it's the perfect AbstractionLayer. But it's there and with the contributor-base for LDAP being rather sparse I think it makes sense to try to keep one AbstractionLayer stable and current instead of creating multiple ones that after a brief intense period will rust away...

[csarrazi]

Ping @fabpot

[Maks3w]

When I wrote FR3DLdapBundle started using the PHP builting LDAP functions but I've found for to deal with the whole universe of LDAP vendors (Microsoft, Linux, ...) an abstraction layer is needed.

Then I thought I could maintain to versions and allow the developer to customize when use builtin functions or Zend\Ldap, finally I've found maintain the builtin functions is a waste of time.

I think it's possible to work in a single implementation and fix any issues.

Disclaimer: While I'm related to zendframework organization my experience with SF2 LDAP integration (FR3DLdapBundle) is previous to my relation with zend-ldap.