Question

I am getting the exact situation described in ApachePasswords

That report was for Apache on Windows. I am experiencing the same problem on a Unix ISP account. I complete the registration form and all goes well until I tyr to login to edit a page, and then authentication fails.

I notice that I have 2 different style lines in .htpasswd, and I have no idea how that happened other than that the first I did from work and the second I did from home.

   GaroldJohnson:{SHA}eh87HnDOeAJ4MJ73N6vz59ylJo4=
   TestGuest:FekjhaFYkKW5s

I will run some more tests, but this is strange.

• TWiki version: 12 Dec 2001
• Web server: Apache/1.3.6 (Unix) mod_ssl/2.3.5 OpenSSL/0.9.3a
• Server OS: bsdos
• Web browser: Opera 6.01, Netscape 4.7
• Client OS: Win98SE

-- GaroldJohnson - 18 Mar 2002

Answer

Very odd - my initial suggestion is to add writeDebug lines to TWiki.cfg to output the results of OS detection (print $OS), as perhaps this is client dependent (can't imagine why). I assume you only have one TWiki installation? There is a specific line for bsdos in TWiki.cfg so this should work.

Then, try adding debug lines to the register script to see where it starts thinking that it is on Windows...

Also, try creating a new user from work and see if it goes in as SHA1 or normal.

A quick hack that should work is to force $OS in TWiki.cfg to be UNIX.

-- RichardDonkin - 19 Mar 2002

I added a display of $OS to testenv, and it shows UNIX. I will try further tests in the register script.

I added a NewGuest with the password of Test and it generated a .htpasswd line of

   NewGuest:QN0pd9ZN9qSHU

There is only one TWiki installation on the site. It is in a subdirectory, but nearly all of it appears to be working fine except for this.

Thanks,

-- GaroldJohnson - 20 Mar 2002

The testenv in CookbookActivePerlTestenv now shows $OS, but it's important here to do a writeDebug( "OS is $OS" ); within the register script, because that will let you associate the $OS value with the decision to use SHA1. Hope this helps.

-- RichardDonkin - 20 Mar 2002

I added a debugWrite to the register script as:

if( $TWiki::OS eq "WINDOWS" ) {
    require MIME::Base64;
    require Digest::SHA1;
}

&TWiki::writeDebug( "Register: \$OS_str is '$Twiki::OS_str'" );
&TWiki::writeDebug( "Register: \$OS is '$Twiki::OS'" );

The output in debug.txt was:

21 Mar 2002 - 11:18 Register: $OS_str is ''

21 Mar 2002 - 11:18 Register: $OS is ''

I added $OS_str to TWiki.cfg and TWiki.pm to hold the original value of $OS. It comes through as empty, so $OS should have become 'UNIX', but it is empty also.

This is not getting any clearer, is it?

Why should it work in testenv and not here? The use TWiki; in register performs a do TWiki.cfg; as it loads, so that should all be handled.

I verified that $OS is not referenced in any of the TWiki::*.pm modules, so they can't change it. I can't find anywhere that $OS is set other than the identification section within TWiki.cfg.

-- GaroldJohnson - 21 Mar 2002

This took me way too long to figure out - the problem is that you have TWiki spelt as 'Twiki', i.e. lower case 'W'. Part of the problem in finding this is that the Perl warnings from the -w flag go to the Apache error_log (usually somewhere like /var/logs/httpd/error_log) - you will see some there about an uninitialised value. Really the script should use strict to make this easier to spot - or perhaps CGI::Carp should throw warnings to the browser as well...

Anyway, on putting the following in register at the same point, I got WINDOWS on my Windows box:

&TWiki::writeDebug( "Register: \$OS is '$TWiki::OS'" ); # Upper case W...

If you put this in, you should be able to tell if/when OS detection is failing.

-- RichardDonkin - 21 Mar 2002

I apologize for that piece of stupidity. With the correction the result is:

21 Mar 2002 - 14:17 Register: $OS_str is 'bsdos'

21 Mar 2002 - 14:17 Register: $OS is 'UNIX'

Now that that is ok, I will track it further to see if I can find anywhere it changes, but there are no assignments that I can find.

I really appreciate the help. I haven't done much debugging of complex CGI scripts, but that is no excuse for not checking syntax prior to doing an upload.

Inside htpasswdGeneratePasswd I get:

21 Mar 2002 - 14:27 htpasswdGeneratePasswd: $OS is 'UNIX'

The lines in .htpasswd are being generated as expected (not SHA1) but authentication still fails immediately after registration and from then on.

-- GaroldJohnson - 21 Mar 2002

Well, at least we are making progress

What is the exact message you are getting when 'authentication fails', including any HTTP error numbers such as 401.x?

Also, please paste in the lines from the Apache error_log file for the time when you have this problem, and the contents of your twiki/bin/.htaccess file.

-- RichardDonkin - 21 Mar 2002

I get a message box from Netscape: "Authorization failed. Retry?" with Ok and Cancel buttons. There are no messages in the browser.

I am hosted on an ISP and don't know where to find error logs. It would seem that they should be somewhere, but I caqn't yet locate them.

the .htaccess file is:

[File snipped once the problem was resolved -- 22 Mar 2002]

The problem was that the path to the .htpasswd file needed to be a Unix path and not a URL path.

At least part of this is working in that edit causes an authorization request.

-- GaroldJohnson 21 Mar 2002

The .htaccess file does look OK, except that the path for the htpasswd file must be a Unix file path, not a URL, e.g.:

AuthUserFile /var/www/htdocs/HiddenVilla/TWiki/data/.htpasswd.  

This is probably what is causing the problem.

I had a quick look around your server (you need to set suitable Apache options to prevent directory indexing btw, and to prevent access to the data and templates directories from the web), and it also looks OK.

One other thing to try is to edit the data/.htpasswd file to remove the blank line and the GaroldJohnson line, delete the GaroldJohnson.txt* files, and then re-register. It's possible that the odd format including blank line is causing problems. If this doesn't work, just truncate the .htpasswd file to 0 bytes and try again.

Also, you really need to ask your ISP for the location of the error log file before we go any further, and to see the errors relating to these problems. If you have Telnet/SSH support, cd to /var/log and look under there (e.g. httpd). The error log message probably says 'can't find htpasswd', which would have pointed out the problem immediately.

See TWikiDebugging for some more resources on debugging.

-- RichardDonkin - 22 Mar 2002

The combination of changing the path to the password file anc cleaning it git the entire thing to work!

You have given me a lot of help, which I appreciate greatly.

I took the liberty of changing the support status to 'AnsweredQuestions', and removing the paste of the .htaccess file.

Thanks,

-- GaroldJohnson - 22 Mar 2002