Summary | Auth::get... in hooks |
Queue | Horde Base |
Queue Version | HEAD |
Type | Bug |
State | Resolved |
Priority | 1. Low |
Owners | jan (at) horde (dot) org |
Requester | adrieder (at) sbox (dot) tugraz (dot) at |
Created | 05/07/2006 (6973 days ago) |
Due | |
Updated | 08/04/2006 (6884 days ago) |
Assigned | 05/11/2006 (6969 days ago) |
Resolved | 08/04/2006 (6884 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Resolved
only in the hook run *after* the authentication.
The preferences are reloaded right before the authentication for
technical reasons, during this run Auth::getAuth() is empty of course.
I am having also issues on calling Auth::getBareAuth() or
Auth::getAuth() on hooks.php. Auth::getBareAuth() worked on Horde
3.1.1, but it's broken on Horde 3.1.2.
alternative...
I am having also issues on calling Auth::getBareAuth() or
Auth::getAuth() on hooks.php. Auth::getBareAuth() worked on Horde
3.1.1, but it's broken on Horde 3.1.2.
Reason why i need that, is that i want search from_addr from ldap
server (with _prefs_hook_from_addr fuction). And i need username for
search. Is there any other way to get username of current session?
I think this is major problem in bigger installations of Horde/IMP.
called only on login now?
called only on login now?
reproduce them, and the weird thing is that the backtraces to both
calls are absolutely identical and at the same time.
gets called 4 times at login?
So a short summary:
1. If a user logs in the first time on the system the hook
"_prefs_hook_from_addr" gets called 4 times.
2. On all subsequent logins, the hook gest called 2 times.
3. On every logout the hook gets called 4 times.
p.s: please remove my "stupid" :-) patches
Priority ⇒ 1. Low
the Auth object is filled. And there I get false from the various
Auth::get... calls.
authenticated, thus Auth::getAuth() returns false. After
authentication the prefs are reloaded for the authenticated user.
gets called 4 times at login?
As I discovered and tried to explain below, the hook is called before
the Auth object is filled. And there I get false from the various
Auth::get... calls.
But the hook gets recalled later on in the login process and then the
Auth::get... calls also return the desired values.
Now that I know this, I modified the hook in the way that it just
returns if Auth::get... returns false. Before I wasn't checking that
and used the any returned value for doing an ldap lookup. That was
confusing me, because of errors in the subsequent ldap lookups.
Maybe I didn't get everything, but is there a reason why the hook gets
called 4 times at login?
State ⇒ Feedback
looks like you didn't update your configuration.
2 times, where again Auth::get... returns just false.
twice during login.
first two times Auth::get... doesn't work, and then it works.
If the from_addr pref is then set in the prefs, the hook gets called 2
times, where again Auth::get... returns just false.
loadPrefs() is used. It gets the preferences via $prefs->retrieve().
This retrieve() function uses the private method _callHooks() from the
Prefs class.
Now there is one place in imp/login.php where loadPrefs() is called
when the Auth object is cleared. This is when a user logs out (see
imp/login line 92 and 93). I don't know the exact reason why it is
called, but anyway at this point the Auth::get...() methods in th hook
doesn't work.
It is also called via Auth::clearAuth() in which again the auth info
from the Auth object is already removed before the loadPrefs call.
Auth::clearAuth() is also called in imp/login.php when a user logs
out. Therefore the hooks are called twice on a logout and I get also
the errors twice.
I didn't figure out what happens when a user logs in (authentication
is done by IMP), but there it also seams to be the case that the hooks
are called to early or are not recalled again.
Assigned to Jan Schneider
State ⇒ Assigned
like hooks are being called before the user is authenticated, and then
not re-called, or the session cache not being cleared, once
authentication takes place.
New Attachment: Registry.php.patch
New Attachment: Prefs.php.patch
<http://cvs.horde.org/diff.php/framework/Prefs/Prefs.php?r1=1.172&r2=1.173&ty=u>
I'm afraid no
<http://marc.theaimsgroup.com/?l=horde-cvs&m=114678117806849&w=2>
If I copy back the old versions of
"framework/Horde/Horde/Registry.php" and "framework/Prefs/Prefs.php"
the problem is gone.
I used my May 2nd running version and did a incremental cvs update as follows:
cvs update -Pd -D 20060503
-> Auth::get... ok
cvs update -Pd -D 20060504
-> Auth::get... ok
cvs update -Pd -D 20060505
-> Auth::get... ok
cvs update -Pd -D 20060506
-> Auth::get... _not ok_
maybe this helps
install. It's not sexy, but if you could narrow the problem down to a
specific date, and to changes in either IMP, Horde, or the framework,
that'd be extremely helpful.
Is this reproduceable by someone else?
I also tested it by installing the base.php version before this
commit. Still the same problem.
http://cvs.horde.org/diff.php?r1=1.100&r2=1.101&f=imp%2Flib%2Fbase.php
I don't know the exact date when it stopped working, but I know that
the version of May 2nd does not show this behaviour
State ⇒ Feedback
an update on a specific date where it stopped working?
Priority ⇒ 3. High
State ⇒ Unconfirmed
Queue ⇒ Horde Base
Type ⇒ Bug
Summary ⇒ Auth::get... in hooks
Auth::getBareAuth();
Auth::getCredential('password');
Auth::getAuthDomain();
within the hook _prefs_hook_from_addr or _prefs_hook_fullname, these
calls return just "false".
I'm using IMP for handling authentications