PHPUnit needs to use the 4-branch for PHP5.5 and the 5-branch for PHP7. So for testing we have to adapt the requirement to PHPUnit (and possibly other libs as well) to reflect that.

There is a solution to that on #21 (comment)

Forgive me if I'm missing something, but I can't seem to remove a user from a group using this library, or at least in a manner similar to that used in the contrib notes on this page: http://php.net/manual/en/function.ldap-mod-del.php

When i run vagrant up command the following error appears:

The box you're adding has a name different from the name you
requested. For boxes with metadata, you cannot override the name.
If you're adding a box using vagrant box add, don't specify
the --name parameter. If the box is being added via a Vagrantfile,
change the config.vm.box value to match the name below.

Requested name: chef/ubuntu-14.04
Actual name: bento/ubuntu-14.04

Currently Zend\Ldap\Ldap::search() internally calls ldap_sort which is already deprecated in the OpenLDAP-libraries and will become deprecated in PHP. As the sorting only is done client-sided and we can not be sure that there might be other data on the server that should be in between the sorting is not really meaningfull.

We should look for a way to sort the data with the "default" PHP-sorting-functions

Check the tables in a document

TLDR; All tables should be in the format of GHFM using | and - as horizontal and vertical separators respectively

Check all tables are in the correct format. Please don't use leading and trailing | - more information on github flavoured markdown tables can be found here.

This one is bad. Other methods that require an ldap bind to have been made, like Ldap::search(), check if the connection is already bound and call Ldap::bind() if not, so users may be accustomed to skipping calling Ldap::bind() directly in user code. However, Ldap::addAttributes() does not do this, so if the Ldap instance doesn't already have a bound connection, we end up calling ldap_mod_add() with null as the ldap resource. Obviously, that doesn't work, but worse, ldap_mod_add returns null, not false, when it is given a null resource, and we only throw an exception if it returns false. So calling code gets no indication that something is wrong.

#68 and #73 as currently written are also subject to this bug.

I'll submit two PRs for this, one with only new tests that cover this case, and one with tests plus fix.

The test fails in HHVM due to a different sorting.

The ldap_connect still uses host and port due to some long outdated OpenLDAP-Libs. As the OpenLDAP-Lib version supporting connections via LDAP-URI is by now 11 years old, we should be able to get rid of that old and deprecated feature.

So all calls to ldap_connect($host, $port) should be replaced with calls to ldap_connect($ldapUri)

Hi,
according to the documentation the Server Options 'port' parameter say:

The port on which the LDAP server is listening. If useSsl is TRUE, the default port value is 636. If useSsl is FALSE, the default port value is 389.

with the following code:

$options = [
                'host' => 's0.foo.net',
//                'port' => '389',
                'useStartTls' => 'false',
                'accountDomainName' => 'foo.net',
                'accountDomainNameShort' => 'FOO',
                'accountCanonicalForm' => '4',
                'baseDn' => 'CN=user1,DC=foo,DC=net',
                'allowEmptyPassword' => false
            ]
$ldap = new Ldap($options);
$ldap->bind('myuser','mypwd')

i get the exception: Failed to connect to LDAP server: s0.foo.net:0

exception 'Zend\Ldap\Exception\LdapException' with message 'Failed to connect to LDAP server: s0.foo.net:0' in /home/dockerdev/app/vendor/zendframework/zend-ldap/src/Ldap.php:748
Stack trace:
#0 /home/dockerdev/app/vendor/zendframework/zend-ldap/src/Ldap.php(812): Zend\Ldap\Ldap->connect()
#1 /home/dockerdev/app/module/DipvvfModule/src/DipvvfModule/Check/LdapServiceCheck.php(57): Zend\Ldap\Ldap->bind('[email protected]...', 'Intr4n3t101177!')
#2 /home/dockerdev/app/vendor/zendframework/zenddiagnostics/src/ZendDiagnostics/Runner/Runner.php(123): DipvvfModule\Check\LdapServiceCheck->check()
#3 /home/dockerdev/app/vendor/zendframework/zftool/src/ZFTool/Diagnostics/Runner.php(43): ZendDiagnostics\Runner\Runner->run(NULL)
#4 /home/dockerdev/app/vendor/zendframework/zftool/src/ZFTool/Controller/DiagnosticsController.php(234): ZFTool\Diagnostics\Runner->run()
#5 /home/dockerdev/app/vendor/zendframework/zend-mvc/src/Controller/AbstractActionController.php(82): ZFTool\Controller\DiagnosticsController->runAction()
#6 [internal function]: Zend\Mvc\Controller\AbstractActionController->onDispatch(Object(Zend\Mvc\MvcEvent))
#7 /home/dockerdev/app/vendor/zendframework/zend-eventmanager/src/EventManager.php(444): call_user_func(Array, Object(Zend\Mvc\MvcEvent))
#8 /home/dockerdev/app/vendor/zendframework/zend-eventmanager/src/EventManager.php(205): Zend\EventManager\EventManager->triggerListeners('dispatch', Object(Zend\Mvc\MvcEvent), Object(Closure))
#9 /home/dockerdev/app/vendor/zendframework/zend-mvc/src/Controller/AbstractController.php(118): Zend\EventManager\EventManager->trigger('dispatch', Object(Zend\Mvc\MvcEvent), Object(Closure))
#10 /home/dockerdev/app/vendor/zendframework/zend-mvc/src/DispatchListener.php(93): Zend\Mvc\Controller\AbstractController->dispatch(Object(Zend\Console\Request), Object(Zend\Console\Response))
#11 [internal function]: Zend\Mvc\DispatchListener->onDispatch(Object(Zend\Mvc\MvcEvent))
#12 /home/dockerdev/app/vendor/zendframework/zend-eventmanager/src/EventManager.php(444): call_user_func(Array, Object(Zend\Mvc\MvcEvent))
#13 /home/dockerdev/app/vendor/zendframework/zend-eventmanager/src/EventManager.php(205): Zend\EventManager\EventManager->triggerListeners('dispatch', Object(Zend\Mvc\MvcEvent), Object(Closure))
#14 /home/dockerdev/app/vendor/zendframework/zend-mvc/src/Application.php(314): Zend\EventManager\EventManager->trigger('dispatch', Object(Zend\Mvc\MvcEvent), Object(Closure))
#15 /home/dockerdev/app/tools/zf.php(53): Zend\Mvc\Application->run()
#16 {main}

if we uncomment the 'port' option everything work fine.

Check code blocks are correct

TLDR; Check in all files that codeblocks are correct, in PSR-2 format and have PHP syntax highlighting applied.

Code blocks should be in the following format...

```php
 'ZEND-FRAMEWORK');

// No required options
$rendererOptions = array();
$renderer = Barcode::factory(
    'code39', 'image', $barcodeOptions, $rendererOptions
);

```

Note the three backticks then php in the opening fence, and the closing fence is just three backticks. It's common for the opening backticks to have no code type, or something like source.

Code should also have been automatically formatted into PSR-2 format, but sometimes these slip through the net.

Check headers are correct

TLDR; Headers should use the #, ## etc to format different levels of headers, and not be underlines using ===== or ``-----`, or be psuedo header using bold

Check all headers on the documentation - headers should use the hash style of declaration rather then be underlined with equals or dashes. The more hashes, the more of a subheading. Eg:

• # is equal to <h1>
• ## is equal to <h2>
• ### is equal to <h3>
• #### is equal to <h4>
• ##### is equal to <h5>

Headings should be appropriate for their level in the documentation.

Psuedo headers using bold tags ** should be replaced with appropriate level of heading tag.

There is no method that implements ldap_mod_add to add multiple values ​​to a field.

The default Error-Handler does not catch Errors.

Thanks to @sgehrig for mentioning and reaching out. A test for the problem can be found at https://gist.github.com/sgehrig/1e1cab662ed1d857b5a2895edc1e7730 though you might have to replace the "zendframework/zend-ldap" : "~2.7" with "zendframework/zend-ldap" : "2.7.0" to make this test succeed once the issue is fixed.

Originally requested at zendframework/zendframework#2780. Now that ZF requires PHP 5.5, we can rely on ldap_control_paged_result to send the paging control option and consume all entries. It's simply a matter of implementing it within the API.

A straightforward way that returns a complete array after pulling all pages follows. This solution improves on a similar one posted on SO, by reusing the base methods as much as possible. However, I feel that:

• This is hackish. It jumps through hoops to access the result ID and it conflates the idea of "desired maximum number of entries" (sizelimit) with "number of entries to request per page".
• A final solution should include an Iterator for pages, with an InnerIterator for entries.

Unfortunately, I've not had luck with a design that addresses these concerns. Ideas welcome.

    public function searchAllEntries(
        $filter, $basedn = null, $scope = self::SEARCH_SCOPE_SUB,
        array $attributes = [], $sort = null, $collectionClass = null,
        $sizelimit = 0, $timelimit = 0
    )
    {
        // calculate page size, then remove it from the filter as we need
        // ldap_search to grab as many as it can, per page
        $pagesz = ($filter['sizelimit'] ?: ($sizelimit ?: 500));
        unset($filter['sizelimit']);

        // run the loop, grabbing pages
        $ldap   = $this->getResource();
        $result = [];
        $cookie = '';
        ErrorHandler::start(E_WARNING);
        ldap_set_option($ldap, LDAP_OPT_PROTOCOL_VERSION, 3);
        do {
            ldap_control_paged_result($ldap, $pagesz, true, $cookie);

            // run the search and add in the results
            $collection = $this->search(
                $filter, $basedn, $scope, $attributes, $sort, $collectionClass,
                null, // no size limit: we need maximum per page
                $timelimit
            );
            $result = array_merge($result, $collection->toArray());

            // get that pesky search result resource handle, which is a
            // private member of the collection's inner iterator
            $inner = $collection->getInnerIterator();
            $steal = function (DefaultIterator $it) { return $it->resultId; };
            $steal = \Closure::bind($steal, null, $inner);
            $entry = $steal($inner);

            // get the next page cookie
            ldap_control_paged_result_response($ldap, $entry, $cookie);
        } while (! empty($cookie));

        // ensure that subsequent reads don't attempt to use paging
        ldap_control_paged_result($ldap, 0);
        ErrorHandler::stop();

        return $result;
    }

• Update Travis configuration
• Check Travis results

Remove the default dependency to the \Zend\StdLib\ErrorHandler by replacing it with an injectable ErrorHandler.

The main aim would be to get rid of external dependencies to make the component as independent as possible and allow a more widespread usage.

This has been influenced by zendframework/zendframework#7497 and symfony/symfony-docs#5756

This is a "reopen" of zendframework/zendframework#6299

I just ran into the same problem. The comparison in isChildOf is case sensitive in regard to the attribute values (not the attribute names which have been changed to lower case before). This is incorrect if the attribute is, for instance, of type DirectoryString using matching rule caseIgnoreMatch for equality match.

For example, we use base DN "ou=people,o=ldap". A user DN might be "uid=test,ou=People,o=ldap" (note the capital "P").

isChildOf won't match in this case, even though the user DN is of a child of the base DN. This is incorrect as the ou attribute must be checked case insensitive.

As a quick workaround I modified the line

if ($cdn[$i + $startIndex] != $pdn[$i]) {

in Dn.php to this test:

$result = array_udiff_uassoc($cdn[$i + $startIndex], $cdn[$i + $startIndex], 'strcasecmp', 'strcasecmp');
if (! empty($result) ) {

This compares attribute names and values case insensitive. Of course, this is not complete as whitespace should be removed as well and some attributes in the DN might actually be case sensitive. Thus I guess ideally, the test should be done by an ldap query instead...

Hey there,

could you introduce a function (I'd sugg. append()?) that uses ldap_mod_add() ?

Right now the only way to push values to the LDAP server is via update(), and for this to work I have to push the old value plus the new values. For a multi-value field such an array can get very large.

This is particularly troublesome, if you update e.g. the "member" attribute in a GroupOfNames object, which is used by openldap's memberof overlay. if I update the server with probably thousands of values, this might lead to a server timeout, cause the memberof overlay does "stuff" (updates? index? sanity checks?).
We could avoid this difficulties, if we'd only append (like ldap_mod_add() does) a new value, instead of pushing the whole array back. Unfortunately Zend\Ldap doesn't offer this mechanism.

I've noticed that there are some DateTime-Typehints that should be replaced with DateTimeInterface to allow passing of DateTimeImmutable as well.

Hi,
I'd like to ask about how receptive this project might be to these new features:

• Support for ldap_sasl_bind(). I don't think there's a workaround -- getResource() will ldap_bind().
• Add an option to request that the library transparently reconnect, rebind and retry in case of failure. I currently have an issue with my in-house ldap connection handling where if a script binds and then hangs out for awhile, openldap times out the connection. A library like this seems to be the appropriate layer to intercept and deal with server timeouts.
• Define an interface with the core CRUD operations currently implemented in Zend\Ldap\Ldap, and have Zend\Ldap\Ldap implement the interface. This would broaden the possibilities for unit test development, from the point of view of applications that use of this library.

Our in-house codebase is starting to be limited by primitive ldap encapsulation and connection handling. If all these enhancements could be merged in, using your library looks like it could be a good solution for us.

Thanks for your consideration
Mike Baynton

It seems as if one of the primitive ldap CRUD operations, manifested in the php API as ldap_mod_replace(), is not wrapped by zend-ldap. Is this an intentional omission for some reason? I can add it if not.

Hello together,

to move to PHP7 the PR #16 from @heiglandreas is needed to avoid the deprecation warning.

Is it possible to release a new tag in the next time?

Currently most of the tests are skipped on travis as they require testing against an existing LDAP.

This PR enables an LDAP-Server on Travis to run the tests again so that only 4 tests of the testsuite are currently skipped.

This test expects the error-message "Can't contact LDAP server" but in PHP 7 the error-message is "Failed to connect to LDAP server". Therefore the build fails in PHP 7.

A check whether this is PHP 7 or PHP 5 or HHVM might make sense here.

This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/7521
User: @Maks3w
Created On: 2015-05-14T06:43:14Z
Updated At: 2015-06-03T17:28:47Z
Body
Since PHP 5.6 the function ldap_escape allow escape input contextually for FILTER and DN.

This could be an improvement over the current manual process

https://github.com/zendframework/zf2/blob/master/library/Zend/Ldap/Filter/AbstractFilter.php#L86
https://github.com/zendframework/zf2/blob/master/library/Zend/Ldap/Converter/Converter.php#L35

Polyfill http://stackoverflow.com/a/8561604/1163444

Check docs for other problems

TLDR; Cast your eye over the documetation for any problems not covered in the other issues

Things slip through the net, so check the documentation for other problems that have been missed. Common other problems include

• Bullet lists (should be single * then space at the start of line)
• Inline code - should be marked by three backticks at start and finish
• bookdown.json file is correctly formated and has the right escaping
• Links between documentation using RST have been stripped
• Any other RST has been removed correctly
• Anything and everything not covered

If you end up fixing the same problem over and over, please ping Gary Hockin - we may be able to add bespoke issue for that problem, or fix in automated capacity

Currently a lot of tests appear to fail with HHVM. So those issues should be fixed

composer error:

$ composer require zendframework/zendframework
Using version ^2.5 for zendframework/zendframework
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - zendframework/zend-ldap 2.5.1 requires ext-ldap * -> the requested PHP extension ldap is missing from your system.
    - zendframework/zend-ldap 2.5.0 requires ext-ldap * -> the requested PHP extension ldap is missing from your system.
    - zendframework/zendframework 2.5.0 requires zendframework/zend-ldap ~2.5.0 -> satisfiable by zendframework/zend-ldap[2.5.0, 2.5.1].
    - Installation request for zendframework/zendframework ^2.5 -> satisfiable by zendframework/zendframework[2.5.0].


Installation failed, deleting ./composer.json.

I don't use ldap... Of course I can add all dependencies one by one but still with 2.4 there was no problem

Check the document for bad blockquoutes

TLDR; Check blockquotes are formatted correctly using > and check headings in blockquotes are using ###

Blockquotes are donated by a single greater than character and then a space. Make sure all the blockquotes in every doc file are correctly formatted. Headings in blockquotes should use ### and not bold.

Any paragraph spacing in blockquotes should be marked using a single greater than, then a space.