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

Michael J Rubinsky mrubinsk at horde.org
Mon Mar 4 16:00:34 UTC 2013


Quoting James MacLean <macleajb at ednet.ns.ca>:

> On 03/01/2013 01:37 PM, Michael J Rubinsky wrote:
>>
>> Quoting James MacLean <macleajb at ednet.ns.ca>:
>>
>>> 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*)))
>>
>> I agree. Somebody with more experience with our Ldap code will have  
>> to take a look at this. Perhaps you should create a ticket on  
>> bugs.horde.org so this doesn't get lost.
>>
>>
> Ticker 12089 created.
>
> I managed to find a better change to Ldap.php that I included in the  
> ticket. A foreach was not pulling out the key and using your  
> Horde:Debug info, saw that key value was never able to be used. so  
> going to turba/lib/Driver/Ldap.php and changing the  
> _buildSearchQuery foreach ($criteria as $vals) to foreach ($criteria  
> as $key => $vals)
> and checking for the $key === 'OR' returned a better search string  
> that returns valid values.
>
> I doubt though it is the correct solution :).

Your analyses sounds reasonable, I'll take a close look during my next  
block of coding time.

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/horde/attachments/20130304/338a9ae0/attachment-0001.bin>


More information about the horde mailing list