[horde] ActiveSync GAL setup help - search returns no contacts
James MacLean
macleajb at ednet.ns.ca
Mon Mar 4 13:38:03 UTC 2013
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 :).
thanks for all the help,
JES
More information about the horde
mailing list