Comment 25 for bug 1172106

Reviewed: https://review.openstack.org/82397
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=ebb59a75cecc71ca7cc137e16056a4c8b513fd8d
Submitter: Jenkins
Branch: master

commit ebb59a75cecc71ca7cc137e16056a4c8b513fd8d
Author: John Dennis <email address hidden>
Date: Sat Mar 22 11:19:56 2014 -0400

    Refactor LDAP API

    The fake LDAP API must emulate the python-ldap API as much as possible
    otherwise much of the LDAP testing is invalid. The python-ldap API
    only accepts utf-8 encoded strings. However, the fake LDAP API accepts
    any Python type therefore properly handling type conversion into and
    out of the LDAP API is not exercised by the fake LDAP API during
    testing. Currently type conversion is done inside the LdapWrapper
    which calls the python-ldap API, this means unicode issues only appear
    when testing with a live LDAP server.

    LdapWrapper and FakeLdap logically are two different providers of the
    same API, as such they should behave identically. Which LDAP API is
    used at run time a configurable option.

    We need a mechanism by which we can substitute an LDAP API and then
    wrap the calls to that API with type conversions. Type conversion
    wrapping replaces the Python types used in Keystone with the types
    needed for the LDAP API, calls the LDAP API, and then type converts
    the results back from LDAP to those used by Keystone.

    This patch establishes an LDAP API interface (LDAPHandler), modifies
    fake LDAP to support it, replaces LdapWrapper with the interface
    (invoking python-ldap) and adds another LDAPHandler instance which
    will be the common location for type conversions prior to calling the
    configured LDAP interface. See the LDAPHandler class definition for
    details).

    This patch is exclusively a refactoring patch anticipating a
    subsequent patch to properly handle unicode values. There is no
    significant change in functionality with this patch, it is just
    refactoring to more cleanly seperate API boundaries. A few tests which
    exercised unicode were disabled in this patch because they will not
    work until the next patch which adds back in correct unicode
    handling. The idea here is to separate out the refactoring needed to
    support unicode from the actual unicode changes, this should make
    reviewing easier.

    Partial-Bug: 1172106
    Change-Id: I7db24040689245a616332b08744f40ab8381579d