archive_me1Add my vote for this tag authentication1Add my vote for this tag create new tag
, view all tags

Implemented : Configurable PasswordFile handling

I am merging Pavel's patch, with POD docco into HtPasswdUserDotPm.

the configuration will be in the TWiki.cfg file

#                   Password file format/encoding method :
#                   htpasswd:plain, htpasswd:crypt, htpasswd:md5 (currently unsupported),
#                   htpasswd:sha1, htdigest:md5
#default htpasswd:crypt;
$htpasswdFormatFamily = "htpasswd";
if( $OS eq "WINDOWS" ) {
   $htpasswdEncoding   = "sha1";   #windows apache 
} else {
   $htpasswdEncoding   = "crypt";
#                   Pathname of user name/password file for authentication :
if ( $htpasswdFormatFamily eq "htpasswd" ) {
   $htpasswdFilename   = "$dataDir/.htpasswd";
} elsif ( $htpasswdFormatFamily eq "htpasswd" ) {
   $htpasswdFilename   = "$dataDir/.htdigest";
#                   pvgoran: authentication "realm" (must be the same as in
#                   password file, MUST NOT contain colons):
$authRealm          = "Enter your WikiName. (First name and last name, no space, no dots, capitalized, e.g. JohnSmith). Cancel to register if you do not have one.";

the $htpasswdFormatFamily will eventually be used to determine which of the UserDotPm packages to load (when we add LDAP, NT, NIS ...)


  1. update the TWikiDocumentation

TODO (Post Cairo) :

  1. update the CodevDocumentation


  1. Determine how you can set your identity when using NoPasswdUserDotPm (ie if the web server is not doing it, and you don't have a SessionPlugin installed.)

In the current (13.03.2003) version of TWiki, the way PasswordFile is handled is hardcoded in 'register', 'passwd' and 'installpasswd'. I believe this is wrong, because if the default "crypt"-encoded passwords can't be used (for example, with TWikiOnWindowsUsingApache) or not wanted, the administrator have to modify these files by himself (and make mistakes, and test, and debug, and so on smile ).

I implemented ConfigurablePasswordFileHandling, so that the administrator can choose between using .htpasswd with "nop" (plain), "crypt", MD5, SHA1 encryption, or using .htdigest (with MD5 encryption - I think there are no other possibilities?); the preferred way is selected with $htpasswdFormat configuration variable. The implementation is still incomplete - I only made 'register' work.

A few notes about implementation:

  • I think this PasswordFile stuff should go to a separate TWiki:: module or to TWiki.pm, because it's used in three files.
  • In order to make "digest" authentication work, I had to replace the colon in the default TWiki authentication prompt by the period. (Because this text defines the "auth realm" that is a part of colon-separated lists in .htdigest.) I also introduced another configuration variable - $authRealm - for this text.
  • I don't have easy access to any Unix system, so I can't test all the mentioned .htpasswd formats. Could someone help?
  • When "non-default" format is used, some of Digest:: Perl modules is required. At now, I do "require Digest::...;" just before the needed function is called, to avoid unnecessary dependencies. Is this a right way of doing such things?

-- PavelGoran - 13 Mar 2003

Good to see this! I was meaning to do something like this (see TWiki page about MD5 and SHA1 authentication somewhere) since it's needed for Apache 2.0 on Windows. Also the code was quite un-modular as you noticed.

A module under TWiki:: would be best, TWiki.pm is already large enough. Something like TWiki::PasswordFile perhaps?

I think there's not much alternative to Digest:: type modules - we already require Digest::SHA1 for Apache 1.3.x or earlier on Windows, so there is a precedent. As long as we document what's needed, the main thing is to do a late require, as you are doing, and then update testenv to check for these modules as optional ones, and the TWikiSystemRequirements (once it it in the core - I think it really should be, since it's so basic to getting Apache 2.0 working on some platforms.)

-- RichardDonkin - 14 Mar 2003

I finally found time to complete the implementation, (partially) test and debug it, and "pack" my changes into .diff files. Here they are (register.diff, passwd.diff, installpasswd.diff, TWiki.cfg.diff and bin/.htaccess.txt.diff), along with the new package Htpasswd.pm that implements password file manipulations.


  • .diff files were generated against the last revisions available in CVS (each .diff file contains the corresponding revision number).
  • (Not true anymore - PavelGoran - 28 Jun 2003) I did not test the default password file configuration htpasswd:crypt ("use .htpasswd with crypt password encryption") that is defined in the given TWiki.cfg.diff, since I don't have easy access to a computer running Unix; I only tested htpasswd:plain and htdigest:md5.
  • I wasn't able to quickly translate to Perl the Apache code that produces .htpasswd entry with MD5 encoding, so I didn't implement htpasswd:md5 password file configuration. Maybe someone with deeper knowledge of Apache sources and/or encryption could do this.

-- PavelGoran - 23 Jun 2003

Today I managed to test htpasswd:crypt password file configuration; surprisingly, all related scripts worked without any problems smile , so did Apache's authentication with newly-generated .htpasswd entries.

I also joined all .diff files into one ConfigurablePasswordFileHandling.diff (.diff for TWiki.cfg was additionally slightly corrected), use it instead of separate files.

-- PavelGoran - 28 Jun 2003

only just found this topic. I'll look into it this week (hope i can integrate it now that I have started a similar change)

-- SvenDowideit - 15 Dec 2003

Bumping Feature topic marked as Scheduled for CairoRelease that hasn't been modified recently.

-- SamHasler - 20 Apr 2004

I'd like to use a separate login for a public site, but this appears in bin/register:

    # generate user entry and add to .htpasswd file
    unless( $remoteUser ) {
        if ( ! TWiki::User::AddUserPassword($wikiName, $passwordA ) ) {
            $url = &TWiki::getOopsUrl( $webName, $topic, "oopsregerr" );
            TWiki::redirect( $query, $url );

Maybe something like:

    my $authUser = defined $remoteUser ? $remoteUser : $wikiName;
    if ( ! TWiki::User::AddUserPassword($authUser, $passwordA ) ) {
        $url = &TWiki::getOopsUrl( $webName, $topic, "oopsregerr" );
        TWiki::redirect( $query, $url );

(Pardon my Perl ignorance, I'm a C++ coder and am not sure of the equivalent idiom for that first line.)

-- KennethPorter - 04 Nov 2004

I'm not sure what you mean, but take a look at the RegisterCgiScriptRewrite - it allows custom login names.

-- MartinCleaver - 04 Nov 2004

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff .htaccess.txt.diff r1 manage 1.4 K 2003-06-23 - 12:34 PavelGoran Diff file for bin/.htaccess.txt
Unknown file formatdiff ConfigurablePasswordFileHandling.diff r1 manage 9.5 K 2003-06-28 - 22:31 PavelGoran Diff file with all changes of existing files
Compressed Zip archivezip ConfigurablePasswordFileHandling.zip r2 r1 manage 4.8 K 2003-06-28 - 22:29 PavelGoran .diff file and Htpasswd.pm
Perl source code filepm Htpasswd.pm r2 r1 manage 5.1 K 2003-06-28 - 22:37 PavelGoran lib/TWiki/Htpasswd.pm
Unknown file formatdiff TWiki.cfg.diff r1 manage 1.1 K 2003-06-23 - 12:34 PavelGoran Diff file for lib/TWiki.cfg
Unknown file formatdiff installpasswd.diff r1 manage 2.3 K 2003-06-23 - 12:33 PavelGoran Diff file for bin/installpasswd
Unknown file formatdiff passwd.diff r1 manage 3.1 K 2003-06-23 - 12:32 PavelGoran Diff file for bin/passwd
Unknown file formatdiff register.diff r1 manage 1.9 K 2003-06-23 - 12:31 PavelGoran Diff file for bin/register
Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2008-09-15 - TWikiJanitor
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.