[Tickets #7418] Re: Unable to write filters to prefs with ldap backend (binds without password)

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7418
------------------------------------------------------------------------------
  Ticket             | 7418
  Updated By         | simon at simonandkate.net
  Summary            | Unable to write filters to prefs with ldap backend
                     | (binds without password)
  Queue              | Ingo
  Version            | 1.2.1
  Type               | Bug
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Horde Developers
------------------------------------------------------------------------------


simon at simonandkate.net (2009-05-04 21:58) wrote:

The patch fixes it for me... Mostly... :) Thanks.

This patch means that the rules are successfully entered in LDAP, and  
are remembered, so functionally at least I am now able to store the  
rules in LDAP along with all other preferences.

There's still an issue somewhere though, not sure where - Ingo is  
still trying to do an LDAP binds as user somewhere without a password  
being obtained.

Ingo throws an error "The preferences backend is currently unavailable  
and your preferences have not been loaded. You may continue to use the  
system with default settings" under the following circumstances:

With Ingo prefs set to use preference system, which is set in Horde  
setup to LDAP, logout.

Login, go to Filters, and click on the Spam rule. It throws the error.  
However, any changes that are made are successfully retained. Any  
future access to the Spam rule in the current session does NOT throw  
the error. The error appears to be cosmetic only, as full  
functionality is retained.

I can reproduce the same error under the same circumstances with Ingo  
set to use SQL for preferences, so Ingo is still trying to do an  
anonymous LDAP bind somewhere else. My LDAP logs confirm:

May  5 11:32:28 server01 slapd[1156]: conn=66725 op=2 BIND  
dn="uid=simon,ou=users,dc=simonandkate,dc=lan" method=128
May  5 11:32:28 server01 slapd[1156]: conn=66725 op=2 RESULT tag=97  
err=53 text=unauthenticated bind (DN with no password) disallowed

As stated, these occur with either preferences system / LDAP backend  
or SQL backend.