Strange authentication/cookie problem

[James Noyes]

Apologies to those who receive this twice, but I wasn't sure if the issue I'm
having is Horde-related or Imp-related - or possibly both.

I'm a long-time Horde 1.2.x/IMP 2.2.x user, now attempting the upgrade to Horde
2.0/IMP 3.0.  I provide webmail for about 30 domains, and want to be sure all
the kinks are worked out before making the new version accessible to the end
users.  I'm impressed with what I see so far, and hopefully my remaining issues
will turn out to be easily corrected.

My setup: Apache 1.3.22/PHP 4.1.1/MySQL 3.23.47/qmail 1.03 with various patches/
Courier-IMAP all running on Solaris 8

I'm 100% functional with Horde 1.2.x/IMP 2.2.x on this platform, and have even
made some custom patches to this Horde/IMP code to allow handling multiple
domains from a single installed Horde/IMP directory.

I also use virtual hosting, and therefore do not use the /horde directory under
my web root.  http://webmail.(somedomain).com/ is meant to go directly to the
Horde system.  With Horde 1.2.x/IMP 2.2.x, this was easy - I simply set the
document root to /path/to/horde/install/imp, made an alias called /horde/ that
pointed to /path/to/horde/install/, and all was well.

With Horde 2.0/IMP 3.0, things needed to be set up differently.  I pointed my
document root directly to /path/to/horde/install/ and uncommented the lines in
/path/to/horde/install/config/registry.php that (according to the instructions)
should enable authentication via IMP and prevent the "double-login" problem.  I
also adjusted all references in registry.php that pointed to '/horde' so they
are now '' or '/' as appropriate.  I even fixed the timezones so they would work
on Solaris - I must admit that had me stumped for a while.

The system seems to work perfectly, with just one small problem.  After logging
in, if I "Reload" under Netscape, or "Refresh" under IE, the Horde "summary"
page generates two identical errors at the top, one right after the other:

Warning: unserialize() failed at offset 0 of 35 bytes in
/root/of/horde/install/lib/Auth.php on line 227

Even after this error occurs, the system still seems to function.  I can
continue to check, send, and manage mail until I log out.  Of course, the simple
solution is "Well, don't reload or refresh", but of course I can't prevent my
end users doing that from time to time, and if they see an error message I can
be sure my phone will ring.  I need to find a way to stop the error from
occuring.

While investigating this error, I discovered that it is related to the cookies
used to (apparently) track session and authentication.  Turning on cookie
notification lets me watch what happens.  During initial login, the system sets
two cookies  - "Horde" and "imp_key".  "Horde" appears to be used for PHP
session management.  "imp_key" seems to be related to the authentication
somehow, but I am not sure what its purpose is.

During a "reload", or a "refresh", the system attempts to set a new cookie,
"auth_key".  If I allow this cookie to be set, the summary page generates the
two errors seen above.  If I choose to NOT allow this cookie to be set, the
summary page does NOT generate the error message, and all seems well.  So it
seems another trivial solution would be to disallow the new cookie.  Trouble is,
normal cookie behavior is to allow the cookie without prompting, so this isn't
really a workable solution for the end users either.

The ultimate question I NEED an answer to is:  How do I fix this?

More specific questions I would LIKE answers to include:
  Can someone explain to me why is this happening?
  Is this a result of a misconfiguration on my part?
  I know it's unlikely, but is this possibly a bug in Horde/IMP?
  Can someone explain the purpose and operation of the <whatever>_key cookies?
  Why does setting an additional <whatever>_key cookie generate an error?
  How do I (or can I?) prevent that second cookie being set?

I'm looking forward to any suggestions.  This is one of only two hurdles I need
to overcome before I switch over to the new Horde/IMP, and I'd love to make that
switch very soon!  The other hurdle was the lack of a password change function,
but it appears that the solution I was looking for just appeared on the IMP
list! :)

Cheers,
James Noyes
(jnoyes@retrogeeks.com)

-------------------------------------------------
This mail sent via testmail.retrogeeks.com