Ok, I have modified that particular setting in the horde/config/conf.php, but still get the same results from Internet Explorer 6/7. I decided to take a look at the headers, and this is what I discovered ...
[Firefox] Connection: keep-alive Referer: https://webmail.unb.ca/horde-313/imp/ Cookie: Horde=d2bee48b14034e9aede601ca872b6f95; imp_key=3d76386d5ec1e810a4845e6088826fd7; auth_key=3d76386d5ec1e810a4845e6088826fd7 [IE7] Cache-Control: no-cache Cookie: imp_key=9100351d21af6b4962ce1f2dfb5e1b17; auth_key=33315dea60316e923cbd109943c71c2e; Horde=3ae9ed92a7b12b65e3c05fa6b0a34c26; Horde=d46441fe7c468ed1f2b51b73ac9f1779 Notice that in IE6 (and IE7) php makes the attempt to set a new sessionid due to authentication, but the initial horde sessionid is not overwritten, and this is causing IE to get confused on where to go, and since the initial horde sessionid is available first in the cookie, it is using it as the sessionid, which is an unauthenticated session. If we make the same connection directly to one of the systems in the cluster, the horde sessionid is replaced properly. I think we might be down to a specific php issue, but not entirely sure. I'm still investigating, but if anyone who has more experience with php sessions that I do wants to pipe in, I wouldn't mind suggestions. Terry Terry Soucy, Systems Analyst Integrated Technology Services University of New Brunswick, Fredericton Campus http://www.unbf.ca/its Voice: 506.447.3018 Fax: 506.453.3590 E-mail: [EMAIL PROTECTED] ** ITS is a scent-reduced workplace - www.unbf.ca/its/policies ** Chuck Hagenbuch wrote: > Quoting [EMAIL PROTECTED]: > >> Actually, we are running Horde / IMP on a Linux HA cluster, and if we >> access each system independently, then users can login with no >> troubles, but if they access the address for the cluster then the >> login cycles back to the login page with a log message of "Successful >> Login". We're noticing the same issues with IE6, IE7 and Safari on >> Mac OSX 10.4. Firefox works flawlessly on all operating systems. >> >> The odd issue is, we are running the testing on the SAME cluster that >> we are running our production Horde 2 installation, and we are having >> no problems with any browsers. I'm down to researching the MS >> Anti-phishing implementation (as well as the Safari one), but I'm >> wondering if it is a combination of Horde 3 and phishing filters (due >> to being on an HA cluster) > > Horde 2 allowed URL-based sessions by default. It's possible that > cookies are only working for you for Firefox (for some reason - domain? > missing "."? dunno), but Horde 2 works because of passing the session id > in the URL. Horde 3 turns that off by default because it's a security > risk. It's likely you can fix the problem by either turning URL-based > sessions back on, or fixing the cookie issues. > > -chuck > > --"we are plastered to the windshield of the bus that is time." - Chris > --IMP mailing list - Join the hunt: http://horde.org/bounties/#imp > Frequently Asked Questions: http://horde.org/faq/ > To unsubscribe, mail: [EMAIL PROTECTED] -- IMP mailing list - Join the hunt: http://horde.org/bounties/#imp Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: [EMAIL PROTECTED]
