No feedback.

Any news?

Yes - didn't do anything for that one because I didn't get any answer 
to my question if such a patch would be welcome and if it should patch 
horde like mentioned below.



I will look after this after 14th Dec.

Are you still going to come up with a patch for this?

I think we have different requirements: We're dealing mostly with 
companies having mail addresses like support@company where two or more 
users are using horde. Actually we have more than 20 support accounts 
and over 130 domains.
What about an alternative solution, that should cover both (and 
future, perhaps more weird) usecases? I'm thinking about an additional 
ldap auth property where you can input a second filter string for all 
ldap_search queries other than login. You can make it optionally 
('Take the login filter'[default], 'Define another'). Wouldn't be that 
big change and would cover the current needs.



If you and the horde developers like that idea I can come up with a patch.

I have the exact same situation on my install.  However, I have 
elected to handle it differently than this solution.



My requirements;

Users can login with just their userid (firstname_lastname)

The userid that gets stored must contain their userid and domain 
(firstname_lastname@example.com)

Listing of users should display only the userid portion - the domain 
is not necessary



Index: login.php

===================================================================

RCS file: /repository/horde/login.php,v

retrieving revision 2.184

diff -u -r2.184 login.php

--- login.php   16 Aug 2005 12:42:15 -0000      2.184

+++ login.php   17 Sep 2005 15:26:02 -0000

@@ -79,7 +79,12 @@

      /* Destroy any existing session on login and make sure to use a

       * new session ID, to avoid session fixation issues. */

      Horde::getCleanSession();

-    if ($auth->authenticate(Util::getPost('horde_user'),

+    $username = Util::getPost('horde_user');

+    if (!strstr($username,"@"))

+    {

+      $username .= "@example.com";

+    }

+    if ($auth->authenticate($username,

                              array('password' => 
Util::getPost('horde_pass')))) {

          $entry = sprintf('Login success for %s [%s] to Horde',

                           Auth::getAuth(), $_SERVER['REMOTE_ADDR']);



Then, use the following hook:



if (!function_exists('_username_hook_tobackend')) {

     function _username_hook_tobackend($userID)

     {

         global $conf;

       $vdomain = $conf['mailer']['params']['localhost'];

         $userID = substr($userID, 0, -(strlen($vdomain)+1));

         return $userID;

     }

}



To do this, I elected to use the mail attribute to authenticate 
against, instead of the uid attribute.  But it displays the results I 
want, gives users a shorter userid to type, and only requires a patch 
to login.php.  Seems less convoluted to me.



I probably could clean up that even more and not require a patch at 
all, if I used the preauthenticate hook, but haven' t had the time to 
do that.

Ok - let's suppose that your $filter is something like this: 
(&(objectClass=posixAccount)(uid=%u@%d))



In our installation this is needed to correctly resolve usernames at 
login (our login names include the domain -> support@banality.de). But 
when you want to list available users (Configuration->Users), then you 
do not want to have the uid query part, because ldap_search yields no 
result w/o %u and %d replacements and they also make no sense for 
searching.



Resumee:



a) We want that filter string for login

b) We do _not_ want the uid part upon listUsers() operation, so we try 
to recognize such (for search purposes malformed) filter strings in 
listUsers() and extract only the objectClass part.

This patch doesn't make any sense. Can please explain *exactly* what 
you're trying to fix?

The ldap auth driver does not list users if you have a custom 
filtering expression like (&(objectClass=posixAccount)(uid=%u@%d)) 
set. Quick fix attached.