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 ...)
TODO :
- update the TWikiDocumentation
TODO (Post Cairo) :
- update the CodevDocumentation
Optional
- 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
).
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.
Notes:
-
.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
, 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 );
return;
}
}
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 );
return;
}
(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