Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="note"><ac:parameter ac:name="title">Under Construction</ac:parameter><ac:rich-text-body>
<p>This proposal is under construction and is not ready for review.</p></ac:rich-text-body></ac:macro>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Ldap Component Proposal

Proposed Component Name Zend_Ldap
Developer Notes
Proposers Shawn Coomey
Andrew Yager
Michelangelo van Dam
Revision 1.2 - 29 March 2007: Updated from community comments and fleshing it out. (wiki revision: 19)

Table of Contents

1. Overview

Zend_Ldap is a component that used to communicate with directory servers that use the LDAP protocol. Provides basic abstraction from built-in PHP ldap functions in a manner similar to Zend_Db.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • Provide communications API for use with any directory server that supports LDAPv3

4. Dependencies on Other Framework Components

  • Zend_Exception

5. Theory of Operation


6. Milestones / Tasks

7. Class Index

  • Zend_Ldap
  • Zend_Ldap_Exception

8. Use Cases


Bind to LDAP server


Bind to LDAP server using autobind


Search for objects

9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jan 22, 2007

    <p>Hi Shawn,</p>

    <p>Is this going to be fleshed out?</p>

  2. Mar 19, 2007


    <p>I would really like this proposal to keep active, as LDAP directory browsing is a very intereseting quiality for professional applications.<br />
    Maybe I can give a help if required.</p>

    <p>I'm trying to start the Zend_Auth_Adapter_LDAP proposal currently...</p>


    1. Mar 29, 2007

      <p>I've heard that there is an LDAP Auth component for Zend_Auth in existance - we discussed it on fw-general in the middle of Jan. Ralf Schindler has some work on such a component:- <a class="external-link" href=""></a></p>

  3. Mar 29, 2007

    <p>I'm really keen to start work on something like this today. Should we be working to do this from scratch so people do not have to have the LDAP component added to PHP, or can we/should we in the interim use the php ldap functions?</p>

    1. May 31, 2007

      <p>I think it is OK to use PHP's ldap module and see what added value we could provide on top of the functions defined there. </p>

  4. Sep 30, 2007

    <p>The most recent changes to provide base functionality to this class are good, however I think that we need to look to be shooting for more of a Zend_Db type functionality where objects are returned which can be iterated through, updates can be performed by changing properties, e.g.:</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    $ldap = new Zend_Ldap(...);
    $objectList = $ldap->search(...);
    foreach ($objectList as $obj)
    $obj->cn = "newCn";

    <p>As it is, we've done little more than abstract the php LDAP layer and made binding a little easier...</p>

    1. Sep 30, 2007

      <p>Seems like a good plan. I'll look into this and will keep you guys informed.</p>

      <p>Tnx for the feedback.</p>

  5. Sep 30, 2007

    <p>I've just started to add some more object style functionality to this API, and updated some of the function calls to make use of the predefined class variables and added some example use cases which work with the Zend_Ldap class as it is now.</p>

  6. Oct 16, 2007

    <p>A thousand pardons for being so negative but .... I'm not impressed.</p>

    <p>This doesn't provide any real features other than to simplify trivial searching scenarios. It's a wrapper class. In fact, it actually hides functionality. There's no way to use controls. It assumes that binding uses a username and password. I suggest that you look at ext/ldap/php_ldap.h in the latest PHP source and get a better understanding of what the raw PHP LDAP API can do. Only then can you safely try to abstract it.</p>

    <p>Here are some ideas for features:</p>

    <li>Provide exception class with error identifiers and a getErrorCode() method for use in conditional expressions (e.g. if ($ex.getErrorCode() == Zend_Ldap_Exception::LDAP_NO_SUCH_OBJECT) ...). There are specific error i<br />
    dentifiers that you'll need to fish out the RFCs.</li>

    <li>Support multiple hosts so that if the operation fails it tries an alternative server. This is a must for a mission critical application in a large IntrAnet environment where there are lots of LDAP servers available a<br />
    nd things are going up an down like yo-yos on "patch tuesday".</li>

    <li>Allow a character encoding to be specified so that string attributes are automatically converted to the right encoding if necessary. Otherwise, someone using ISO-8859-1 encoding for their pages are going to find i18n<br />
    text is not rendered properly.</li>

    <li>Allow the user to specify attribute definitions so that the developer doesn't have to deal with double sub-scripted arrays all over the place.</li>

    <li>Allow the attribute definitions to specify an "automatic conversion". AD uses time values that are nanoseconds since 1601 (yes, really). An automatic conversion could convert that to seconds since 1970 (and better make it a float to preserve precision).</li>

    <li>Use a callback based lower level search API that accepts controls, scope, timeout, everything possible and then build the simple 'search' method on top that.</li>

    <li>Provide a sorting control.</li>

    <p>The raw LDAP API provided by PHP is so hard to use that a good Zend_Ldap module could be a major head turner so I hope someone gets serious about this.</p>

    <p>The Ldap_Object think looks interesting but I think you're going to really need attribute definitions to pull it off. Otherwise how will you know if somethings an integrer or an array of floats.</p>

    1. Oct 22, 2007

      <p>Hi Michael,</p>

      <p>Thanks for your feedback. The purpose for this component is to provide an easy interface for accessing LDAP repositories as an object. More functionality can be extended by more advanced components.</p>

      <p>I'm currently looking into the RFC's to provide meaningfull and compliant error messages, but the basics remain: this is a simple interface for accessing and searching LDAP repositories.</p>

      <p>Extra care will be given to internationalization, but it's going to be an extended part of the basic component, since in many cases UTF-8 will be sufficient.</p>

      <p>We'd appreciate your input for this component and all feedback is welcome.</p>


      1. Oct 23, 2007

        <p>While I understand Michelangelo's desire to keep things simple, one of the beauties of the Zend Framework is that it takes complex tasks and makes them trivial. Many components have with simple implementations, and have later been revised to more substantial versions, but more often than not these have resulted in API changes (take controllers for instance). I think this is what Michael is driving at - a desire for a simple, yet elegantly powerful API to do everything he ever dreamed about with LDAP. (Isn't that what we all really want?)</p>

        <p>While some of these features may not be implemented initially, I can see great benefit in most of the features Michael has said, and think we need to design them in now. Since Zend_LDAP will be used in a variety of LDAP server environments, I think it is important that it correctly handles character encodings via standard PHP/LDAP or Zend interfaces. Multiple servers for failover is in my opinion a much needed addition, not too difficult to build in, and overlooked when I started looking at this component.</p>

        <p>The attribute level decoding should be provided, in my opinion at an Object Level, rather than in the main Zend_LDAP class, and this class should be designed to correctly handle this, and be easily extendable (albeit down the track). The argument for using callback based searching carries a lot of merit as well, as it really about future extensibility.</p>

        <p>In favour of what we have done, much in the same way that Zend_Db provides a simple API for querying a database with some common functionality, and then the more advanced features are built on top of that, I think that Zend_LDAP should provide basic searching and modification (taking care to correctly handle any escaping or encoding that needs to happen), but it must provide a basis for a more advanced (and arguably useful, killer) implementation. I think we are heading that way with what we've got.</p>

        1. Oct 23, 2007


          <p>Because I haven't had the opportunity to use a multi server failover system, I wanted to delay this part. But if you have experience in this field, I can only embrace your decision to implement it.</p>

          <p>I was already researching character encoding because I need this for my current project. I will propose this within the next week. If we can implement this, I think we're already half-way there.</p>

          <p>I agree with you when we start with a basic (but with good encoding functionality) Ldap component, that's ready to be extended by advanced features. </p>

          <p>Too bad that this week I don't have much time to work on it, cause I really believe this component will be a very useful addition to the Zend Framework.</p>

  7. Jan 08, 2008

    <p>Dear All,</p>

    <p>Due to ongoing Zend_Auth_Adapter_Ldap work it was decided that we need to breakout stuff into Zend_Ldap and Zend_Ldap_Exception classes. I have performed that work and created a separate proposal page here:</p>

    <p><a href=""></a></p>

    <p>Note that my proposal doesn't define much other than the connect(), bind() and some account name canonicalization stuff used by the authentication adapter so hopefully I'm not stepping on any toes. What little my proposal has is very consistent, if not identical, to what you have here.</p>