[horde] ActiveSync GAL setup help - search returns no contacts

James MacLean macleajb at ednet.ns.ca
Thu Feb 21 14:15:21 UTC 2013


On 02/21/2013 10:02 AM, Michael J Rubinsky wrote:
>
> Quoting James MacLean <macleajb at ednet.ns.ca>:
>
>> On 02/20/2013 09:22 PM, Michael J Rubinsky wrote:
>>>
>>> Quoting "James B. MacLean" <macleajb at ednet.ns.ca>:
>>>
>>>> On 2013-02-20 1:31 PM, Michael J Rubinsky wrote:
>>>>>
>>>>> Quoting James MacLean <macleajb at ednet.ns.ca>:
>>>>>
>>>>>> On 02/20/2013 02:20 AM, Michael J Rubinsky wrote:
>>>>>>>
>>>>>>> Quoting "James B. MacLean" <macleajb at ednet.ns.ca>:
>>>>>>>
>>>>>>>> On 2013-02-07 2:06 AM, Michael J Rubinsky wrote:
>>>>>>>>>
>>>>>>>>> Quoting "James B. MacLean" <macleajb at ednet.ns.ca>:
>>>>>>>>>
>>>>>>>>>> So, no, I do not know if the LDAP server is being queried 
>>>>>>>>>> from the GAL function properly and I would like to trace that 
>>>>>>>>>> back, but, alas, my php skills for traversing where 
>>>>>>>>>> this->_registry->contacts->search() goes is beyond my skill :(.
>>>>>>>>>> Would you mind pointing out where that function is that is 
>>>>>>>>>> being called and I will keep digging in to it.
>>>>>>>>>
>>>>>>>>> This calls Turba_Api::search() (so, it's in 
>>>>>>>>> turba/lib/Api.php). The actual logic for the search that is 
>>>>>>>>> called from Turba_Api::search() is in a combination of 
>>>>>>>>> Turba_Driver::search() (so, in turba/lib/Driver.php) and 
>>>>>>>>> Turba_Driver_Ldap::_search() (in turba/lib/Driver/Ldap.php).
>>>>>>>>>
>>>>>>>> Ok, getting somewhere now. When you search within Horde in the 
>>>>>>>> "Global Address Book" the filter is :
>>>>>>>>
>>>>>>>> (|(givenname=Maclean, james)(sn=Maclean, 
>>>>>>>> james)(|(displayname=*Maclean, james*)(mail=*Maclean, james*)))
>>>>>>>>
>>>>>>>> Which ties in well with the use of 'strict' settings in 
>>>>>>>> turba/config/backends.local.php . When I do a search in 
>>>>>>>> ActiveSync, it looks like :
>>>>>>>>
>>>>>>>> (&(givenname=Maclean)(sn=Maclean)(|(displayname=*Maclean*)(mail=*Maclean*))) 
>>>>>>>> which will never match for me. The AND appears to be coming from :
>>>>>>>>
>>>>>>>> horde/turba/lib/Driver.php
>>>>>>>>
>>>>>>>> in
>>>>>>>>
>>>>>>>> public function makeSearch
>>>>>>>>
>>>>>>>> inside this if around line 460:
>>>>>>>>
>>>>>>>> if (count($strict_search) && count($search)) {
>>>>>>>>
>>>>>>>> changing that AND to OR gets things moving.
>>>>>>>
>>>>>>> That doesn't seem like the right fix.
>>>>>>>
>>>>>>> Can you see what the value of $query that is passed in to 
>>>>>>> Horde/Core/ActiveSync/Driver.php in the _searchGal() method? I'm 
>>>>>>> thinking I'm building that query incorrectly.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Added :
>>>>>>
>>>>>> error_log("Q=" . print_r($query,true));
>>>>>>
>>>>>> Searching for Macle :
>>>>>>
>>>>>>
>>>>>> Q=Array\n(\n    [query] => Macle\n    [range] => 0-50\n)\n
>>>>>
>>>>> Ok. The query that is being build and passed to the LDAP specific 
>>>>> search routine would be something like this simplified psuedo-ish 
>>>>> search tree for me:
>>>>>
>>>>> [AND]
>>>>> |
>>>>> |---[OR]
>>>>> |     |
>>>>> |     |---{owner_id == 'currentuser'}
>>>>> |
>>>>> |---[OR]
>>>>>     |
>>>>>     |---{firstname == '*bob*'}
>>>>>     |---{lastname  == '*bob*'}
>>>>>     |---{alias == '*bob*'}
>>>>>     |---{email == '*bob*'}
>>>>>
>>>>>
>>>>> So, in other words, at least one part of each [OR] must match for 
>>>>> an entry to be included...so the [AND] *must* be included. Using 
>>>>> an [OR] would end up returning EVERY entry in the source owned by 
>>>>> 'currentuser' since only one of the two sub OR conditions would 
>>>>> need to me met.
>>>>>
>>>>> I'm not an LDAP expert, so I can't comment on how 
>>>>> Turba_Driver_Ldap::_search() translates this tree into ldap 
>>>>> filter, but I would look there.
>>>>>
>>>> So when I am seeing:
>>>>
>>>> (&(givenname=Maclean)(sn=Maclean)(|(displayname=*Maclean*)(mail=*Maclean*))) 
>>>> that and is 'suppose' to connect the owner branch with the search 
>>>> branch, but, the owner branch appears to be :
>>>>
>>>> (givenname=Maclean)(sn=Maclean)
>>>>
>>>> which will never be true :(.
>>>
>>> Well, your search might be different. The first [OR] grouping comes 
>>> from any strict searches, yours may or may not be the same as mine.
>>>
>>> You can dump the value of $criteria in Turba_Driver_Ldap::_search() 
>>> and see the exact structure of the query before it's parsed into an 
>>> LDAP filter.
>>>
>>> BTW, you can use Horde::debug($some_value); to easily output this 
>>> stuff. It will output in a file called 'horde_debug.txt' placed in 
>>> your temporary directory.
>>>
>>>
>>>
>>>
>> If this helps:
>>
>> 16. Horde::debug() /var/www/horde/turba/lib/Driver/Ldap.php:162
>> array(1) {
>>   ["AND"]=>
>>   array(2) {
>>     ["OR"]=>
>>     array(2) {
>>       [0]=>
>>       array(3) {
>>         ["field"]=>
>>         string(9) "givenname"
>>         ["op"]=>
>>         string(1) "="
>>         ["test"]=>
>>         string(7) "Maclean"
>>       }
>>       [1]=>
>>       array(3) {
>>         ["field"]=>
>>         string(2) "sn"
>>         ["op"]=>
>>         string(1) "="
>>         ["test"]=>
>>         string(7) "Maclean"
>>       }
>>     }
>>     [0]=>
>>     array(1) {
>>       ["OR"]=>
>>       array(2) {
>>         [0]=>
>>         array(5) {
>>           ["field"]=>
>>           string(11) "displayname"
>>           ["op"]=>
>>           string(4) "LIKE"
>>           ["test"]=>
>>           string(7) "Maclean"
>>           ["begin"]=>
>>           bool(true)
>>           ["approximate"]=>
>>           bool(false)
>>         }
>>         [1]=>
>>         array(5) {
>>           ["field"]=>
>>           string(4) "mail"
>>           ["op"]=>
>>           string(4) "LIKE"
>>           ["test"]=>
>>           string(7) "Maclean"
>>           ["begin"]=>
>>           bool(true)
>>           ["approximate"]=>
>>           bool(false)
>>         }
>>       }
>>     }
>>   }
>> }
>
> This looks correct. I'm not an LDAP person, but it looks to me like 
> the filter is being built incorrectly from this array. This array is 
> saying that EITHER givenname OR sn must match. The AND is between the 
> results of the first condition and the second OR condition.  Someone 
> with more experience with LDAP will have to track down the issue in 
> Turba_Driver_Ldap::_search().
>
>
>
Just looking at the first part of of the query that gets created :

&(givenname=Maclean)(sn=Maclean)

You can see it does not match the criteria above. That appears to drop 
the 'OR' and leave the 'AND' one level to low. That is, I would 
interpret the criteria above translated to LDap to look more like :

(&(|(givenname=Maclean)(sn=Maclean))(|(displayname=*Maclean*)(mail=*Maclean*)))

JES


More information about the horde mailing list