[horde] IE problems

[Scott Courtney]

On Thursday 05 June 2003 22:19, I wrote:
> Good evening!
>
> I've been to the FAQ and the mail archives, but haven't seen this bug
> reported anywhere.
>
> I have a working Horde configuration that does everything it's supposed to
> do in Konqueror and in Netscape. In IE, however, the upper frame (the one
> with the application, rather than the menu bar) never displays. IE
> complains that it can't locate the host, which I know is utter nonsense
> because it's displaying the other frame from the same host.
>
> IE, of course, even with "friendly error messages" turned off, gives me no
> meaningful error and doesn't tell me *what* hostname it is unable to
> resolve. Typical Micros~1 lack of useful diagnostics.
>
> Has anyone seen this before, and if so, what can I do about it?

With help from a colleage who was able to get IE to produce meaningful data,
I've actually answered my own question. In the Open Source spirit, I'm
posting a "diff" of the changes to the list.

The problem is that Horde's login process, when detecting that the user had
not yet authenticated, was redirecting to the login.php page. Fine so far,
but it obtained the server name for the redirection from
$_SERVER["SERVER_NAME"]. That is *usually* fine, but in some cases the
SERVER_NAME, which is the host's canonical hostname, is not the same as the
hostname visible to the user's web browser. In our case, the server sits
behind a firewall that does redirection, so *outside* users see something
like "webmail.example.com" while the host's physical name is
"webmail01.facility.example.com", a name not resolvable on the external DNS
server. The externally-resolved name is in $_SERVER["HTTP_HOST"].

The file that needed to be changed is config/registry.php. Here is the
output of "diff -U 3" on the before and after files:

[webmail01] $ diff -U3 registry.php.before registry.php
--- registry.php.before 2003-06-09 11:02:43.000000000 -0500
+++ registry.php        2003-06-09 11:03:32.000000000 -0500
@@ -87,13 +87,13 @@
     'allow_guests' => true,
     'status' => 'active',
     'templates' => dirname(__FILE__) . '/../templates',
-    'cookie_domain' => $_SERVER['SERVER_NAME'],
+    'cookie_domain' => $_SERVER['HTTP_HOST'],
     // ** If IE will be used to access Horde modules, you should read
     //    this discussion about the cookie_path setting (discussing issues
     //    with IE's Content Advisor):
     //   
 http://lists.horde.org/archives/imp/Week-of-Mon-20030113/029149.html
 'cookie_path' => '/',
-    'server_name' => $_SERVER['SERVER_NAME'],
+    'server_name' => $_SERVER['HTTP_HOST'],
     'server_port' => $_SERVER['SERVER_PORT']
 );

I can't say I've tested this "exhaustively", but a quick confidence test does
show that it clears up the problem. The error was occurring repeatably
before, so its absence gives me fairly good confidence that this is a real
fix for the problem. I don't have the time right now to test against CVS
HEAD, unfortunately. This was against the stable 2.2.3 version of Horde and
IMP version 3.2.1.

As far as I can tell, the other places SERVER_NAME appears in the Horde/
Turba/IMP source tree, it's actually okay. Only this one file appears to be a
problem. I don't use the other Horde application packages in this site, so
I can't tell you if any of them are affected.

Kind regards,

Scott

-- 
-----------------------+------------------------------------------------------
Scott Courtney         | "I don't mind Microsoft making money. I mind them
courtney at 4th.com       | having a bad operating system."    -- Linus Torvalds
http://4th.com/        | ("The Rebel Code," NY Times, 21 February 1999)
                       | PGP Public Key at http://4th.com/keys/courtney.pubkey