I use TwikiRegistrationPub (copied to TwikiRegistration) to create new users, they are entered in the .htpasswd but when I try to log in and enter the password . These passwords do not match and I get the 401 'Authorization Required'.

BTW When I Use TwikiRegistrationPub i get the message 'Authorization failed' in Red.

-- NorbertKlamann - 02 Aug 2000

Have you check the permissions on the .htpasswd file?

Try adding a user:password pair by hand with:

   # htpasswd -c .htpasswd 
   [..new password stuff...]

-- NicholasLee - 02 Aug 2000

Forgot to mention: The whole thing runs under Windows NT.

I checked with htpasswd and created a password '1' with htpasswd and registered a twiki user with the same password. There are differences indeed:

htpasswd -c -d a TestA gives :

TestA:$apr1$DR1.....$BZr29bUW3s/ZT7c73Bf561 

...
TestA:DqDie/9IWa3dU

in .htpasswd

-- NorbertKlamann - 03 Aug 2000

They aren't going to be to same, since the salt (first two characters of the stored password I think) generally is random.

Is the hand added htpasswd user able to access the TWiki Web?

Note the code used in register to generate the passwd entry is basically copied from: http://world.inch.com/Scripts/htpasswd.pl.html

-- NicholasLee - 03 Aug 2000

Yes, when I copy over the password entry all works fine. Seems as if Apache has a new algorithm to handle these things. I have the new Version 'Apache/1.3.12 (Win32)' .

-- NorbertKlamann - 03 Aug 2000

Could be the version of crypt that is used on Win32. Seems like its time to hunt down some documentation.

From the looks of the htpasswd usage output:

[...]
On Windows and TPF systems the '-m' flag is used by default.
On all other systems, the '-p' flag will probably not work.

I'm not sure how Apache deals with different crypted versions of the passwd..

-- NicholasLee - 04 Aug 2000

I checked the Apache documentation. Apache added a modified MD5 encryption to Apache 1.3.4 (released 11 January 1999) on Windows.

From http://www.apacheweek.com/issues/99-01-29#encrypted :

Encrypted passwords on Windows

In releases of Apache for Windows upto version xxx, passwords in .htpasswd files are stored unencrypted. This is because Windows does not contain a standard function for encrypting strings (on Unix, the crypt() function does this).

From version xxx, string encryption has been added to Apache using the MD5 algorithm. This means that encrypted passwords can now be used with Apache. The Apache server and the htpasswd program have both been updated to work with MD5 encrypted passwords. On Windows, all passwords will now be encrypted with MD5. Unix will default to using crypt() for encrypting passwords, although it is possible to use MD5 instead (using the new -m option to htpasswd).

I downloaded the Apache 1.3.14 source and found this file in src\support

#!/usr/bin/perl -w
use strict;
#
# Utility which takes a username and password
# on the command line and generates a username
# sha1-encrytped password on the stdout.
# 
# Typical useage:
#    ./htpasswd-sha1.pl dirkx MySecret >> sha1-passwd
#
# This is public domain code.  Do whatever you want with it.
# It was originally included in Clinton Wong's Apache 1.3.6 SHA1/ldif
# patch distribution as sample code for generating entries for
# Apache password files using SHA1.

use MIME::Base64;  # http://www.cpan.org/modules/by-module/MIME/
use Digest::SHA1;  # http://www.cpan.org/modules/by-module/MD5/

if ($#ARGV!=1) { die "Usage $0: user password\n" }

print $ARGV[0], ':{SHA}', encode_base64( Digest::SHA1::sha1($ARGV[1]) );

Sites that use Apache on Windows should modify the function htpasswdGeneratePasswd in the register script to reflect the MD5 algorithm instead of the Unix crypt() one.

-- PeterThoeny - 04 Dec 2000

That means: add the following five lines (marked with "+") to register.pl and authentication works:

*** register    Tue Jul 17 02:30:24 2001
--- register.pl Wed Jul 18 11:32:28 2001
***************
*** 23,26 ****
--- 23,29 ----
  use TWiki::Net;

+ use MIME::Base64;
+ use Digest::SHA1;
+
  $query = new CGI;

***************
*** 188,191 ****
--- 191,196 ----
  {
      my ( $user, $passwd ) = @_;
+     # early return
+     return $user . ':{SHA}' . encode_base64(Digest::SHA1::sha1($passwd));
      # by David Levy, Internet Channel, 1997
      # found at http://world.inch.com/Scripts/htpasswd.pl.html

-- RalfHandl - 20 Jul 2001

Is it an idea to put this in the distributed code, in combination with some variable set in th configuration, on which it executes this part of disregards it?

-- HansDonner - 11 Aug 2001

I think this is a good idea, Windows setting can exist in TWiki.cfg and can also set up a few values in TWiki.cfg as well as being used to alter behaviour in a few places such as this.

-- JohnTalintyre - 11 Aug 2001

This is great and I hope it makes it into the pending release! I'm not sure I see the need to add a cfg variable since I'm fairly sure getting some $platform variable must be a standard feature?

If this is true, all one would need would be something like (pseudo code):

sub htpasswdGeneratePasswd

if ($platform == "windows")
    $passwd = $htpasswdGeneratePasswdWin;
else $passwd = $htpasswdGeneratePasswdUnix;

# save new username & password to .htaccess file.
$writeUser($username, $passwd)

return

sub htpasswdGeneratePasswdWin
# as from above for windows
# Optionally check a cfg variable for $USINGWINSECURITY = 1
# and generate it via some api call that can use the 
# Windows Security Manager. (Future Idea)

return $passwd

sub htpasswdGeneratePasswdUnix
# as original for unix

return $passwd

sub writeUser($username, $passwd)
# Do the write(sic) thing for the os/webserver being used.
# Potentially, one could tie this into (for example), the NT
# security system and store the user and password according to that method.
# (Future Idea)

return 1 # success or 0 failure

Rocket science I know, but hope every little bit helps.

-- DavidLeBlanc - 12 Aug 2001

Alternatively we could default to SHA encryption for both UNIX and Windows platforms...

-- MartinCleaver - 12 Aug 2001

Better a switch in TWiki.cfg and default to crypt() since this reduces the Perl module dependencies of TWiki.

-- PeterThoeny - 12 Aug 2001

I saw this was not yet done in the beta of aug 17th...

-- HansDonner - 19 Aug 2001

Made change based on OS detection code from CGI.pm. Please check.

-- JohnTalintyre - 24 Aug 2001

I saw the changes made in the CVS tree. It's looking good. I'll update my code with teh changes made and see how it'll work...

Note: in testenv the rcs commands are checked by verifiying the existence of ci. In case of Windows this should be ci.exe

-- HansDonner - 24 Aug 2001

The testenv script should be changed to be aware of the platform (now in latest TWiki.cfg) and test for external programs accordingly. Also the diff command should be checked.

• I've now put an improved version of testenv into CVS that knows about .exe files - doesn't yet do diff checking because it would need to search the PATH -- RichardDonkin

-- PeterThoeny - 25 Aug 2001

I am experiencing exactly the same symptoms on a Unix system (BSDOS) running Apache 1.3.6 with the 12 Dec 2001 TWiki code.

I thought that it might be due to constraints on the structure of passwords, but I tried a password that works on the rest of the system, and that didn't fix it.

This is an ISP hosted account, so I do not have root access.

-- GaroldJohnson - 13 Mar 2002

Garold - it would be best to start a new question in the Support web, and fill that in with as much detail as possible on your problem, including the contents of .htpasswd lines added by register.

-- RichardDonkin - 13 Mar 2002