6.0.0-git
2019-08-21

[#8246] LDAP Prefs backend, kronolith tries to bind w/o password
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 2009-05-06 (3759 days ago)
Due
Updated 2009-06-16 (3718 days ago)
Assigned 2009-05-12 (3753 days ago)
Resolved 2009-06-16 (3718 days ago)
Milestone
Patch No

History
2009-06-16 13:37:51 Jan Schneider Comment #7
State ⇒ Duplicate
Reply to this comment
Closed in favor of the catch-all ticket #8353.
2009-05-15 15:46:54 m (dot) rolke (at) linux-ag (dot) com Comment #6
New Attachment: 0005-fix-8246-LDAP-Prefs-backend-kronolith-tries-to.patch Download
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.
2009-05-12 23:31:10 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?
2009-05-12 14:07:05 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.
2009-05-07 21:56:40 simon (at) simonandkate (dot) net Comment #3 Reply to this comment

[Show Quoted Text - 31 lines]
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.
2009-05-07 12:27:02 m (dot) rolke (at) linux-ag (dot) com Comment #2
New Attachment: 0003-fix-8246-LDAP-Prefs-backend-kronolith-tries-to.patch Download
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.
2009-05-06 11:08:38 simon (at) simonandkate (dot) net Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ LDAP Prefs backend, kronolith tries to bind w/o password
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
New Attachment: kronolith.jpg Download
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.

Saved Queries