Opened 4 years ago

Closed 4 years ago

#1485892 closed Feature Requests (fixed)

gn and givenName should be synonymous in LDAP addressbook

Reported by: duelli Owned by:
Priority: 5 Milestone: 0.3.1
Component: LDAP connection Version: git-master
Severity: normal Keywords:
Cc:

Description

We are using OpenLDAP on a Debian Etch server as an addressbook for Roundcube.

We only define the field givenName for the firstname of the contacts in the addressbook.

When using

$rcmail['ldap_public']['firstname_field'] = 'gn';

the firstname of a user cannot be retrieved.

For example, ldapsearch yield the same results for the following two calls, regardless of whether gn or givenName is set.

ldapsearch -x -ZZZ gn=Michael gn
ldapsearch -x -ZZZ givenName=Michael givenName

Roundcube should behave in the same way.

Of course, the current workaround is to use

$rcmail['ldap_public']['firstname_field'] = 'givenName';

but Roundcube does not seem to know that these two attributes are the same.

Change History (10)

comment:1 Changed 4 years ago by duelli

Probably this is related to bug http://trac.roundcube.net/ticket/1485830

comment:2 Changed 4 years ago by alec

  • Component changed from Addressbook to LDAP connection
  • Milestone changed from 0.3-stable to 0.4-beta
  • Type changed from Bugs to Feature Requests

So, are you saying that we should replace gn with givenName when talking to LDAP server? I cannot find this in RFC.

comment:3 Changed 4 years ago by alec

  • Milestone changed from 0.4-beta to 0.3-stable
  • Resolution set to fixed
  • Status changed from new to closed

Ok, I've found it. Fixed in [4368a079].

comment:4 follow-up: Changed 4 years ago by duelli

  • Resolution fixed deleted
  • Status changed from closed to reopened

Your patch breaks the ldap search for me completely (no matter I use gn or givenName).

Search worked in [08ff050e] and stopped working in [4368a079].

I found that this "fix" will make the search work again...

Index: program/include/rcube_ldap.php
===================================================================
--- program/include/rcube_ldap.php      (revision 2896)
+++ program/include/rcube_ldap.php      (working copy)
@@ -57,8 +57,8 @@
       if (preg_match('/^(.+)_field$/', $prop, $matches))
         $this->fieldmap[$matches[1]] = $this->_attr_name(strtolower($value));

-    foreach ($this->prop['required_fields'] as $key => $val)
-      $this->prop['required_fields'][$key] = $this->_attr_name(strtolower($val));
+//    foreach ($this->prop['required_fields'] as $key => $val)
+//      $this->prop['required_fields'][$key] = $this->_attr_name(strtolower($val));

     $this->sort_col = $p['sort'];

Then, gn as well as givenName work.

comment:5 in reply to: ↑ 4 Changed 4 years ago by alec

Replying to duelli:

Search worked in [08ff050e] and stopped working in [4368a079].
I found that this "fix" will make the search work again...

Are you sure? 'required_fields' are not related to searching. Works for me (gn, givenname and givenName) on OpenLDAP. Show your config.

comment:6 Changed 4 years ago by duelli

Well, at least this config works with [08ff050e] but not with [4368a079] ...

$rcmail_config['ldap_public']['MyLDAP'] = array(
  'name'          => 'MyLDAP',
  'hosts'         => array('ldap.somewhere.com'),
  'port'          => 389,
  'use_tls'       => false,
  'user_specific' => false,   // If true the base_dn, bind_dn and bind_pass default to the user's IMAP login.
//  // %fu - The full username provided, assumes the username is an email
//  //       address, uses the username_domain value if not an email address.
//  // %u  - The username prior to the '@'.
//  // %d  - The domain name after the '@'.
  'base_dn'       => 'ou=people,o=somewhere',
////  'bind_dn'       => '',
////  'bind_pass'     => '',
  'writable'      => false,   // Indicates if we can write to the LDAP directory or not.
  'ldap_version'  => 3,       // using LDAPv3
  'search_fields' => array('mail', 'cn'),  // fields to search in
  'name_field'    => 'cn',    // this field represents the contact's name
  'email_field'   => 'mail',  // this field represents the contact's e-mail
  'surname_field' => 'sn',    // this field represents the contact's last name
  'firstname_field' => 'gn',  // this field represents the contact's first name
  'sort'          => 'cn',    // The field to sort the listing by.
  'scope'         => 'sub',   // search mode: sub|base|list
  'filter'        => '',      // used for basic listing (if not empty) and will be &'d with search queries. example: status=act
  'fuzzy_search'  => true);   // server allows wildcard search

comment:7 Changed 4 years ago by alec

The same config works for me. slapd-2.4.9, php-5.2.10.

comment:8 Changed 4 years ago by duelli

For me it is php-5.2.8 and, more important, only OpenLDAP 2.3.30. (Debian Etch)

Can this be an OpenLDAP 2.3 -> 2.4 issue?

comment:9 Changed 4 years ago by duelli

Just found the problem myself!

My config does not define 'required_fields', so this will result in an error in the foreach loop as a key => value is applied on a null value which is also given in HTML output

'<br />
<b>Warning</b>:  Invalid argument supplied for foreach() in <b>/srv/roundcube/program/include/rcube_ldap.php</b> on line <b>60</b><br />

(Loops without key-value association work fine.)

I think that this will also break other older installations. Here is my proposed patch.

Index: program/include/rcube_ldap.php
===================================================================
--- program/include/rcube_ldap.php      (revision 2921)
+++ program/include/rcube_ldap.php      (working copy)
@@ -57,6 +57,10 @@
       if (preg_match('/^(.+)_field$/', $prop, $matches))
         $this->fieldmap[$matches[1]] = $this->_attr_name(strtolower($value));

+    // Check configuration on 'required_fields' entry.
+    if (!isset($this->prop['required_fields']))
+       $this->prop['required_fields'] = array();
+
     foreach ($this->prop['required_fields'] as $key => $val)
       $this->prop['required_fields'][$key] = $this->_attr_name(strtolower($val));

comment:10 Changed 4 years ago by alec

  • Resolution set to fixed
  • Status changed from reopened to closed

Fixed in [38066281].

Note: See TracTickets for help on using tickets.