6.0.0-alpha12
6/17/25

[#7418] Unable to write filters to prefs with ldap backend (binds without password)
Summary Unable to write filters to prefs with ldap backend (binds without password)
Queue Ingo
Queue Version 1.2.1
Type Bug
State Duplicate
Priority 1. Low
Owners
Requester johannes.nilsson (at) sorch (dot) se
Created 09/30/2008 (6104 days ago)
Due
Updated 06/16/2009 (5845 days ago)
Assigned 10/07/2008 (6097 days ago)
Resolved 06/16/2009 (5845 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
06/16/2009 01:37:47 PM Jan Schneider Comment #15
Taken from Horde DevelopersHorde Developers
State ⇒ Duplicate
Reply to this comment
Closed in favor of the catch-all ticket #8353.
05/07/2009 01:37:41 PM m (dot) rolke (at) linux-ag (dot) com Comment #14 Reply to this comment
Kronolith is doing the same thing.
Should I do a new bug report?
I see you already did this for kronolith: http://bugs.horde.org/ticket/8246

I've created another bug for nag: http://bugs.horde.org/ticket/8251



Now for ingo, we have two patches, fixing the following three places:
ingo/lib/Storage.php:749:            $prefs = 
Prefs::factory($GLOBALS['conf']['prefs']['driver'],
fixed with storagephp(2).patch
ingo/lib/Storage/prefs.php:36:        $prefs = 
&Prefs::singleton($GLOBALS['conf']['prefs']['driver'],
fixed with 0001-fix-7418-Unable-to-write-filters-to-prefs-wit.patch
ingo/lib/Storage/prefs.php:133:        $prefs = 
&Prefs::singleton($GLOBALS['conf']['prefs']['driver'],
fixed with 0001-fix-7418-Unable-to-write-filters-to-prefs-wit.patch
05/06/2009 09:59:54 AM simon (at) simonandkate (dot) net Comment #13 Reply to this comment
Kronolith is doing the same thing. With LDAP preference backend set, 
first new calendar entry after a login generates a bind as user with 
no password and the "Preference system not available message". LDAP 
log entry:



May  6 18:25:18 server01 slapd[1156]: conn=73358 op=2 BIND 
dn="uid=simon,ou=users,dc=simonandkate,dc=lan" method=128

May  6 18:25:18 server01 slapd[1156]: conn=73358 op=2 RESULT tag=97 
err=53 text=unauthenticated bind (DN with no password) disallowed



Should I do a new bug report?
05/05/2009 08:13:09 AM Jan Schneider Deleted Original Message
 
05/05/2009 03:05:37 AM simon (at) simonandkate (dot) net Comment #12
New Attachment: storagephp(2).patch Download
Reply to this comment

[Show Quoted Text - 9 lines]
Patch file was "diff'ed" the wrong way :) Can someone with permissions 
remove the earlier one please?
05/05/2009 02:16:32 AM simon (at) simonandkate (dot) net Comment #11
New Attachment: storagephp.patch
Reply to this comment
Found it! :)



ingo/lib/Storage.php - it also has the "Ingo::getUser(), '', null, 
false);" line that it calls to try and find . I replaced that with 
"Ingo::getUser(), Auth::getCredential('password'), null, false);" and 
it has resolved the issue.



Patch file attached. never done one before, so I hope it's OK.


05/05/2009 01:58:55 AM simon (at) simonandkate (dot) net Comment #10 Reply to this comment
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.
05/04/2009 12:31:08 PM m (dot) rolke (at) linux-ag (dot) com Comment #9
New Attachment: 0001-fix-7418-Unable-to-write-filters-to-prefs-wit.patch Download
Reply to this comment
attached a patch for ingo
At least in those cases where we explicitly use the current user's
preferences, i.e. where we don't try to access preferences of other
users, this makes sense. A patch that fixes all those places would be
great.
04/17/2009 03:19:08 PM Jan Schneider Comment #8 Reply to this comment
At least in those cases where we explicitly use the current user's 
preferences, i.e. where we don't try to access preferences of other 
users, this makes sense. A patch that fixes all those places would be 
great.
04/17/2009 02:49:48 PM m (dot) rolke (at) linux-ag (dot) com Comment #7 Reply to this comment
I can confirm this bug, too.

The users password is needed when the option

         $conf['prefs']['params']['writedn']

in the horde conf.php is set to 'user'.



Adding the users password as the fourth argument in the "$prefs = 
&Prefs::singleton" call fixed this issue for me. Thank you urkle for 
this tip (Comment #3)!



Sadly, this bug appears not only in ingo but in kronolith and some 
other horde apps, too.

I did a quick search in my horde directory and found many other calls 
to the Prefs::singleton function, where the password argument is an 
empty string.



So, is there a reason why applications should not pass the users 
passwort to the singleton function?

I would prefer the method of writing preferences to the LDAP as the 
logged-in user instead of writing as admin.



Thank you in advance!
04/04/2009 03:11:21 PM simon (at) simonandkate (dot) net Comment #6 Reply to this comment
I have the same problem using kolab. Is there a solution for this?
Will there be a patch?
Ditto - exactly the same issue. CVS is the same.



When set to LDAP backend, Ingo tries to bind unauth and gets rejected. 
Result is that when you first go to Filters after logging on, you get 
the Preferences unavailable message, and no filters are saved from the 
session.



Set to SQL backend it is fine, although some actions still seem to 
trigger a call to the preferences system in my setup (LDAP) and return 
the same message, but with no functionality impact that I can see.
01/16/2009 11:00:04 AM syntron (at) web (dot) de Comment #5 Reply to this comment
I have the same problem using kolab. Is there a solution for this? 
Will there be a patch?
12/31/2008 03:25:40 AM urkle (at) outoforder (dot) cc Comment #4 Reply to this comment
OK, if I remove arguments 4-6 don't set a password, and more 
importantly don't override the 6th argument ($cache) with false and 
leave the default to TRUE, it works as well..



Is there any specific reason WHY in the case of ingo, the 6th arg is 
set to false????




12/31/2008 03:22:39 AM urkle (at) outoforder (dot) cc Comment #3 Reply to this comment
I am also having this issue when using the LDAP backend for Prefs with 
horde 3.3.2/ingo 1.2.1. I did not have this issue with horde 3.1.1.   
I have located the cause of the issue and implemented a *workaround* 
in my install to allow it to work.



In ingo/lib/Storage/prefs.php lines 38-40 an instance of the Prefs 
singleton is generated but w/ a blank password (the 4th argument).   
If I set the 4th arg to Auth::getCredential('password')  then ingo 
works correctly..   I also am changing that on line 139.



back in horde 3.1.x ingo's pref driver would access a global $prefs 
object instead of using the singleton object.
10/07/2008 01:23:33 PM Jan Schneider State ⇒ Assigned
Assigned to Horde DevelopersHorde Developers
 
09/30/2008 08:34:23 PM johannes (dot) nilsson (at) sorch (dot) se Comment #2 Reply to this comment
  I have horde setup to let imp handle the authentication.
I just changed this to let horde handle the authentication itself 
(auth driver ldap). It works fine, but made no difference to the 
filter problem.
09/30/2008 07:20:39 PM johannes (dot) nilsson (at) sorch (dot) se Comment #1
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Summary ⇒ Unable to write filters to prefs with ldap backend (binds without password)
Type ⇒ Bug
Queue ⇒ Ingo
Reply to this comment
  I have horde setup to let imp handle the authentication. Imp talks 
to cyrus which talks to ldap. I have no problems logging in.



I have set up Ingo to use the 'prefs' storage driver. Ingo can read 
and publish filters just fine using the timsieved driver. 
Unfortunately Ingo fails when trying to write the filters to 
prefs/ldap. According to the ldap.log this is because it is trying to 
bind without a password.  It is however possible to change the 'Update 
script...' setting. Settings in other modules are also saved fine.



Versions:



horde-ingo-1.2.1-1mdv2008.1

horde-imp-4.2-2mdv2008.1

horde-3.2.2-1mdv2008.1





Additional information:



$conf['prefs']['maxsize'] = 2147483647;

$conf['prefs']['params']['hostspec'] = 'localhost';

$conf['prefs']['params']['port'] = 389;

$conf['prefs']['params']['version'] = '3';

$conf['prefs']['params']['basedn'] = 'ou=MailAccounts,dc=example,dc=com';

$conf['prefs']['params']['writedn'] = 'user';

$conf['prefs']['params']['uid'] = 'uid';

$conf['prefs']['driver'] = 'ldap';



$conf['auth']['admins'] = array('Administrator', 'johnil');

$conf['auth']['checkip'] = true;

$conf['auth']['checkbrowser'] = true;

$conf['auth']['alternate_login'] = false;

$conf['auth']['redirect_on_logout'] = false;

$conf['auth']['params']['app'] = 'imp';

$conf['auth']['driver'] = 'application';





I added this (at line 241) to  Prefs/ldap.php:



Horde::logMessage("Inside trying to rebind as :".$this->_dn." with: 
".$this->_password, __FILE__, __LINE__, PEAR_LOG_NOTICE);



From horde.log:



Sep 30 21:01:41 HORDE [notice] [ingo] Inside trying to rebind as 
:mail=johannes.nilsson@example.com,ou=MailAccounts,dc=example,dc=com 
with:  [pid 925 on line 241 of 
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]

Sep 30 21:01:41 HORDE [error] [ingo] Error rebinding for prefs 
writing: [53]: Server is unwilling to perform [pid 925 on line 260 of 
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]

Sep 30 21:01:41 HORDE [error] [ingo] Internal LDAP error.  Details 
have been logged for the administrator. [pid 925 on line 338 of 
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]



And ldap.log:



Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 fd=54 ACCEPT from 
IP=127.0.0.1:35658 (IP=0.0.0.0:389)

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=0 SRCH 
base="ou=MailAccounts,dc=example,dc=com" scope=2 deref=0 
filter="(uid=johnil)"

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=0 SRCH attr=dn

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=0 SEARCH RESULT 
tag=101 err=0 nentries=1 text=

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=1 BIND 
dn="mail=johannes.nilsson@example.com,ou=MailAccounts,dc=example,dc=com" 
method=128

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=1 RESULT tag=97 
err=53 text=unauthenticated bind (DN with no password) disallowed

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18316 fd=55 ACCEPT from 
IP=127.0.0.1:35659 (IP=0.0.0.0:389)

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18316 op=0 SRCH 
base="ou=MailAccounts,dc=example,dc=com" scope=2 deref=0 
filter="(uid=johnil)"

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18316 op=0 SEARCH RESULT 
tag=101 err=0 nentries=1 text=

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18316 op=1 UNBIND

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18316 fd=55 closed

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18317 fd=55 ACCEPT from 
IP=127.0.0.1:35660 (IP=0.0.0.0:389)

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18317 op=0 SRCH 
base="ou=MailAccounts,dc=example,dc=com" scope=2 deref=0 
filter="(uid=johnil)"

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18317 op=0 SEARCH RESULT 
tag=101 err=0 nentries=1 text=

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18317 op=1 UNBIND

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18317 fd=55 closed

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=2 UNBIND

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 fd=54 closed

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 fd=54 ACCEPT from 
IP=127.0.0.1:35661 (IP=0.0.0.0:389)

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=0 SRCH 
base="ou=MailAccounts,dc=example,dc=com" scope=2 deref=0 
filter="(uid=johnil)"

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=0 SRCH attr=dn

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=0 SEARCH RESULT 
tag=101 err=0 nentries=1 text=

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=1 BIND 
dn="mail=johannes.nilsson@example.com,ou=MailAccounts,dc=example,dc=com" 
method=128

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=1 RESULT tag=97 
err=53 text=unauthenticated bind (DN with no password) disallowed

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=2 UNBIND

Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 fd=54 closed

Saved Queries