bad search filter - during specific address book ldap searches

[rcubetrac]

Reported by c schwamborn on 17 Nov 2015 15:12 UTC as Trac ticket #1490591

Hello,

playing with a 1.1.2 version of roundcube and the acl plugins I found a little bug in the ldap search filter compilation.
I've configured an internal global addressbook wich works fine as an addressbook, but when it's used to autocomplete the user search in the acl plugin nothing happend, no user was found. Same setup as an older 1.0.x version which worked.

Assume a fieldmap setup with multiple mail attibutes using the quantifier '*' as documented:

$rcmail_config[= array(
...cut...
'fieldmap' => array(
'name' => 'cn',
'surname' => 'sn',
'firstname' => 'givenName',
'email' => 'mail:*',
),
...cut...

putting some additional debug lines to:

rcube_ldap.php
class rcube_ldap
function search

around line
$filter = rcube_ldap_generic::fulltext_search_filter($value, $attributes, $mode);

logging the content of $value, $attributes, $mode, and finally $filter produced the following output:

==> console <==
15-Nov-2015 22:32:23 +0100: <2upg2e07> foo
22:32:23 +0100: <2upg2e07> array (
0 => 'cn',
1 => 'sn',
2 => 'givenName',
3 => 'mail:',
4 => 'uid',
)
22:32:23 +0100: <2upg2e07> 0
22:32:23 +0100: <2upg2e07> (|(cn=foo)(sn=foo)(givenName=foo)(mail:=foo)(uid=foo))

==> errors <==
22:32:23 +0100: <2upg2e07> PHP Error: ldap_search failed for dn=: Bad search filter (POST /roundcube/?_task=settings&_action=plugin.acl-autocomplete?_task=&_action=)

with the atteched (crude) patch in function fulltext_search_filter, a usefull search filter came up:
(|(cn=foo)(sn=foo)(givenName=foo)(mail=foo)(uid=foo))

The current code on github of this particular function is still the same as in version 1.1.2 I used.

Best regards, Christian

Migrated-From: http://trac.roundcube.net/ticket/1490591

[rcubetrac]

Comment by @alecpl on 17 Nov 2015 16:08 UTC

Confirmed. Thanks for the patch, but the fix belongs to the acl plugin around line 742.

[rcubetrac]

Owner changed by @alecpl on 17 Nov 2015 16:08 UTC

=> alec

[rcubetrac]

Milestone changed by @alecpl on 17 Nov 2015 16:08 UTC

later => 1.1.4

[rcubetrac]

Comment by c schwamborn on 17 Nov 2015 19:00 UTC

Ah I see, fulltext_search_filter is supposed to compile a filter of what ever list is provided without questioning it's content.

[rcubetrac]

Comment by @alecpl on 17 Nov 2015 19:13 UTC

It was a regression from commit [Fixed in 1912d8c(0a96bdf].).

[rcubetrac]

Status changed by @alecpl on 17 Nov 2015 19:13 UTC

new => closed

[rcubetrac]

Comment by c schwamborn on 17 Nov 2015 20:49 UTC

I've seen you closed the ticket and don't want to bother you, but I tested your patch from [the patch (and with my 'hotfix') the filter looked like this (|(cn=*foo*)(sn=*foo*)(givenName=*foo*)(mail=*foo*)(uid=*foo*)) i.e. in all possible ldap attributes from fieldmap was searched.
Now just 'cn' and the ACL user identifier, in this case 'uid', are queried (|(cn=*foo*)(uid=*foo*)) but nothing else - was that intentionally?
shouldn't you keep the content of $config['fieldmap'](1912d8c62b8]. Before) and apply the regex to all of it's values.
Maybe something like this (sorry for the crude code, my php knowledge is limited):

        $config[= array();
        foreach (array_values($config['fieldmap']('search_fields'])) as $val) {
            $config['search_fields'][] = preg_replace('/:.*$/', '', $val);
        }

The result would again be a query in all fieldmap attributes: (|(cn=*foo*)(sn=*foo*)(givenName=*foo*)(mail=*foo*)(uid=*foo*))

[rcubetrac]

Comment by @alecpl on 18 Nov 2015 06:43 UTC

Yes. It is intentional. It is exactly the behaviour from before the regression. We can improve that in some way, maybe by using contactlist_fields option. I think using the whole fieldmap is not the best way.