Tickets :: [#8246] LDAP Prefs backend, kronolith tries to bind w/o password

6.0.0-beta1

7/5/25

Summary	LDAP Prefs backend, kronolith tries to bind w/o password
Queue	Kronolith
Queue Version	2.3.1
Type	Bug
State	Duplicate
Priority	1. Low
Owners
Requester	simon (at) simonandkate (dot) net
Created	05/06/2009 (5904 days ago)
Due
Updated	06/16/2009 (5863 days ago)
Assigned	05/12/2009 (5898 days ago)
Resolved	06/16/2009 (5863 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

06/16/2009 01:37:51 PM	Jan Schneider	Comment #7 State ⇒ Duplicate	Reply to this comment
Closed in favor of the catch-all ~~ticket #8353~~.

05/15/2009 03:46:54 PM	m (dot) rolke (at) linux-ag (dot) com	Comment #6 New Attachment: 0005-fix-8246-LDAP-Prefs-backend-kronolith-tries-to.patch	Reply to this comment
kronolith/lib/Kronolith.php:1796: $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'], needs to be patched. see attachment This is actually the same like in all the other cases, $user might be the current user, but not necessarily. Thus the password should only be used if $user is the current user. Ok, thanks. The updated patch should now do exactly the above.

05/12/2009 11:31:10 PM	simon (at) simonandkate (dot) net	Comment #5	Reply to this comment
kronolith/lib/Kronolith.php:1796: $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'], needs to be patched. see attachment This is actually the same like in all the other cases, $user might be the current user, but not necessarily. Thus the password should only be used if $user is the current user. Jan - without the patch I get an error on Kronolith's first save of a new event after logon. With the patch I don't get the error. So it's working for me. From what you are saying though I understand that there are times that Kronolith uses this code to call users other than the current user at times? In which case does the code need to be split to obtain the password for when it's current user as per the patch that fixes my error message?

05/12/2009 02:07:05 PM	Jan Schneider	Comment #4 State ⇒ Feedback	Reply to this comment
kronolith/lib/Kronolith.php:1796: $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'], needs to be patched. see attachment This is actually the same like in all the other cases, $user might be the current user, but not necessarily. Thus the password should only be used if $user is the current user.

05/07/2009 09:56:40 PM	simon (at) simonandkate (dot) net	Comment #3	Reply to this comment
[Show Quoted Text - 31 lines][Hide Quoted Text] There are five places in kronolith where the preference system is being instanciated: I see only the need to patch one place (see attachment). Please correct me if i'm wrong. grep -n "Prefs::" * -r kronolith/fb.php:36: $prefs = &Prefs::singleton($conf['prefs']['driver'], 'kronolith', $user, '', null, false); the logged-in users password won't help here, because fb.php is accessed by some other user? so there is no need for a patch. kronolith/lib/Kronolith.php:1796: $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'], needs to be patched. see attachment kronolith/lib/api.php:1348: $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'], the alarms of the logged in users should be retrieved via $prefs = &$GLOBALS['prefs']; for other users, the logged-in user password won't help, i think. no patch needed kronolith/scripts/agenda.php:75: $prefs = Prefs::singleton($GLOBALS['conf']['prefs']['driver'], Script, no need for user password. kronolith/scripts/upgrades/convert_to_utc.php:52: $prefs = Prefs::factory($conf['prefs']['driver'], 'horde', Script, no need for user password. Thanks - this fixes the error for me. I grepped for getUser which was the string used in the Ingo issue, should have grepped for Prefs:: as you mentioned.

05/07/2009 12:27:02 PM	m (dot) rolke (at) linux-ag (dot) com	Comment #2 New Attachment: 0003-fix-8246-LDAP-Prefs-backend-kronolith-tries-to.patch	Reply to this comment
There are five places in kronolith where the preference system is being instanciated: I see only the need to patch one place (see attachment). Please correct me if i'm wrong. grep -n "Prefs::" * -r kronolith/fb.php:36: $prefs = &Prefs::singleton($conf['prefs']['driver'], 'kronolith', $user, '', null, false); the logged-in users password won't help here, because fb.php is accessed by some other user? so there is no need for a patch. kronolith/lib/Kronolith.php:1796: $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'], needs to be patched. see attachment kronolith/lib/api.php:1348: $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'], the alarms of the logged in users should be retrieved via $prefs = &$GLOBALS['prefs']; for other users, the logged-in user password won't help, i think. no patch needed kronolith/scripts/agenda.php:75: $prefs = Prefs::singleton($GLOBALS['conf']['prefs']['driver'], Script, no need for user password. kronolith/scripts/upgrades/convert_to_utc.php:52: $prefs = Prefs::factory($conf['prefs']['driver'], 'horde', Script, no need for user password.

05/06/2009 11:08:38 AM	simon (at) simonandkate (dot) net	Comment #1 Milestone ⇒ State ⇒ Unconfirmed New Attachment: kronolith.jpg Patch ⇒ No Queue ⇒ Kronolith Summary ⇒ LDAP Prefs backend, kronolith tries to bind w/o password Type ⇒ Bug Priority ⇒ 1. Low	Reply to this comment
Similar issue to http://bugs.horde.org/ticket/7418 in Ingo - tries to bind to LDAP as user without password. System is using LDAP for preferences. The first time after logging on to the Horde system, saving a new event in Kronolith generates the error message in the attached screenshot. The event saves correctly and is written to SQL as needed. The issue appears to be cosmetic only. Once the error has been thrown, subsequent event saves do NOT produce the error until after a logout / login. LDAP logs show: 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 In Ingo it was a line in Storage.php (see http://bugs.horde.org/ticket/7418), but that's not the case here I don't think.