[dev] Re: [cvs] commit: horde/lib Registry.php

[Michael M Slusarz]

Quoting Chuck Hagenbuch <chuck@horde.org>:

| Quoting Michael M Slusarz <slusarz@bigworm.colorado.edu>:
| 
| >   Log:
| >   Set no forced caching when a user originally logs in (or is reported)
| > as a guest user, but after authentication the user is no longer a
| guest.
| > THis fixes the bug when using IMP as the authentication agent.  Now,
| the
| > hooks will correctly have access to Auth::getUser().
| 
| This is a bug that I was never able to reproduce. I guess I'm still a bit
| skeptical.

OK... after 2 hours of tracking this bug down, I will try to explain it as 
best I can...

When using IMP as the authentication agent (users logging on via 
BASEURL/horde/imp/login.php), the first thing run after reloading 
redirect.php is lib/base.php.  In this file, $registry->pushApp() is 
called.  However, no user authenticaion has happened yet (the username is 
in 'imapuser') so Auth::getAuth() is empty.  $registry->pushApp eventually 
loads the preferences, and the hooks are called at this time (I use a SQL 
backend, and the hooks are called in Prefs_sql::retrieve()).  Once again, 
no authentication has yet taken place so Auth::getAuth() will return 
empty.  Since some of the hooks use getAuth(), it renders these hooks 
useless.

retrieve() is eventually called again later in the instance.  However, it 
used to get to cacheLookup() and exit there -- so not running the hooks 
when getAuth is empty is not enough by itself to fix the problem.  The 
problem, as far as I can tell , is this line in lib/Prefs.php cacheLookup():
array_intersect(array_keys($this->_prefs), $prefs) == $prefs);
that is returning true.  This makes sense since none of the actual 
preferences change when going from guest->user.

Let me know if this makes no sense.

michael

______________________________________________
Michael Slusarz [slusarz@bigworm.colorado.edu]
The University of Colorado at Boulder