Question

We have a problem with our TWiki 4.1.2 installation.

$TWiki::cfg{LoginManager} = 'TWiki::Client::TemplateLogin';
$TWiki::cfg{PasswordManager} = 'TWiki::Users::HtPasswdUser';
$TWiki::cfg{UserMappingManager} = 'TWiki::Users::TWikiUserMapping';

Sometimes logging in takes multiple attempts. When submitting a username and password, the page simply refreshes to the login screen with the fields blank. Returning to another TWiki page shows that the user has not been logged in.

Sometimes it takes as many as 20 attempts to log in correctly. Viewing another TWiki page and then selecting "login" again sometimes seems to help. Problem occurs with a variety of users on a variety of workstations using Firefox and IE6. No proxy is between TWiki and the users.

There is nothing in the apache error logs nor the TWiki logs. In the apache access logs it looks like this:

10.30.144.52 - - [28/May/2008:15:37:23 +1000] "POST /twiki/bin/login/Everest/NTBDBA0001PBchecklist HTTP/1.1" 200 6947
10.30.144.52 - - [28/May/2008:15:37:28 +1000] "POST /twiki/bin/login/Everest/NTBDBA0001PBchecklist HTTP/1.1" 200 6947
10.30.144.52 - - [28/May/2008:15:37:54 +1000] "POST /twiki/bin/login/Everest/NTBDBA0001PBchecklist HTTP/1.1" 302 -

The unsuccessful attempts return a 200, the successful attempts return a 302.

I have also built a TWiki 4.2.0 install on the same server to see if this problem was resolved. It is using LdapContrib as follows but is exhibiting exactly the same problem.

$TWiki::cfg{LoginManager} = 'TWiki::LoginManager::TemplateLogin';
$TWiki::cfg{UserMappingManager} = 'TWiki::Users::LdapUserMapping';
$TWiki::cfg{PasswordManager} = 'TWiki::Users::LdapUser';
$TWiki::cfg{Ldap}{SecondaryPasswordManager} = 'TWiki::Users::HtPasswdUser';

and the problem appears in the log files as:

10.30.144.205 - - [28/May/2008:16:36:00 +1000] "GET /twiki/bin/login/Main/WebHome?origurl=/twiki/bin/view/Main/WebHome HTTP/1.1" 200 7343
10.30.144.205 - - [28/May/2008:16:36:05 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 200 7287
10.30.144.205 - - [28/May/2008:16:36:10 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 200 7287
10.30.144.205 - - [28/May/2008:16:36:14 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 200 7287
10.30.144.205 - - [28/May/2008:16:36:20 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 200 7287
10.30.144.205 - - [28/May/2008:16:36:25 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 200 7287
10.30.144.205 - - [28/May/2008:16:36:32 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 200 7287
10.30.144.205 - - [28/May/2008:16:36:36 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 200 7287
10.30.144.205 - - [28/May/2008:16:36:42 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 200 7287
10.30.144.205 - - [28/May/2008:16:36:48 +1000] "GET /twiki/bin/login/Main/WebHome?origurl=/twiki/bin/view/Main/WebHome HTTP/1.1" 200 7343
10.30.144.205 - - [28/May/2008:16:36:53 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 200 7287
10.30.144.205 - - [28/May/2008:16:36:59 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 200 7287
10.30.144.205 - - [28/May/2008:16:37:09 +1000] "GET /twiki/bin/login/Main/WebHome?origurl=/twiki/bin/view/Main/WebHome HTTP/1.1" 200 7343
10.30.144.205 - - [28/May/2008:16:37:14 +1000] "POST /twiki/bin/login/Main/WebHome HTTP/1.1" 302 -

The good news is that the problem goes away if I disable mod_perl by commenting out in the httpd.conf as so:

# Disabling this fixes login problems
#    SetHandler perl-script
#    PerlResponseHandler ModPerl::Registry
#    PerlSendHeader On
#    PerlOptions +ParseHeaders

However, I would much prefer a solution that doesn't involve losing the mod_perl speedup!

Environment

-- IanDonaldson - 28 May 2008

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

This sounds like an interesting problem. I hate it when I have interesting problems

When I had a similar problem on another application, it was related to cookies: without a cookie for the TWiki session id, the server can't tell that the user was authenticated, and so the loop.

So first check that the client is permitting cookies. Though it probably is accepting them, since it eventually works.

Another possibility is that the users are on an internal network and accessing the web server without a FQDN (fully-qualified domain name), e.g., "http://host" or even "http://<ip address>" instead of "http://host.domain.com". A cookie set for either of the first two won't work on the FQDN request after the redirect.

I have no idea why disabling mod_perl works for you, but it does have a couple of header settings, and of course the cookie is in the headers. The fact that there is nothing in the server error logs doesn't help, so you might need to log the actual requests/responses at the client in order to see what the difference is with and without mod_perl. Assuming you have network folks, they probably know how to do that with Wireshark (formerly Ethereal). But it's much easier to use an HTTP tracing tool:

• ieHTTPHeaders (IE plug-in. Good and free)
• The evaluation version of these commercial products are too disabled to be useful. But for completeness:
  • HTTPWatch (IE plug-in. It's great, the one I use)
  • HTTPLook
  • WebDetetective

(BTW, I read that PerlSendHeader is obsolete and replaced by PerlOptions +ParseHeaders, so maybe you only need the latter?)

-- SeanCMorgan - 29 May 2008

I've used Firefox's HTTP live headers plugin to capture the headers on a failed and working attempt to log in. Unfortunately it appears to me that they are identical except for the working one returning a 302 rather than a 200 and including a Location field for the redirect. So it doesn't look like the problem is on the client end.

-- IanDonaldson - 30 May 2008

Tried updating to mod_perl 2.0.4, but the problem remains.

-- IanDonaldson - 30 May 2008

Built apache 2.2.8 to use in preference to the Solaris-supplied apache and it still exhibits the problem.

-- IanDonaldson - 30 May 2008

I'm having precisely the same problem with TWiki 4.2, Ubuntu 8.04, Apache 2.2.8, Perl 5.8.8 and mod_perl 2.0.3.

-- BruceNourish - 01 Jul 2008

Seems like a mod_perl related issue. I suggest to file a bug report (see link in sidebar)

-- PeterThoeny - 19 Aug 2008