I really hope that this turns to be out as a consequence of my own misconfiguration, otherwise it is a "Requirement" bug blocking the release. Sorry for that. And it would add another nasty example to experimental software engineering in the registration area.
In
Item2309, a minimal password length has been introduced, which is a good thing. However, the default is set to 1, which is bad.
If I have
AllowLoginName
set to true (as is often the case in intranets), then there are no password fields in the registration form. Still ok. But then, during validating the form in
Register.pm
,
_validateRegistration
, the length of the password is compared to the minimal password length - regardless of whether
AllowLoginName
is true, or whether the login manager is
none
.
I can't even work around with adding a dummy password because I lack the form fields.
Set default a bit higher (perhaps use a typical default of ~6 chars for emphasizing the "twiki is secure" aspect), and highlight under configure doc for allowloginname that it should be set to 0 if this is enabled?
--
SP
Not for a bugfix release. This would require everyone who wants to upgrade from 4.0.x to 4.0.3 to re-run
configure
. I'd prefer to have
Register.pm
check whether a password is required automatically, instead of having admins to evaluate whether they need to change the configuration or not. If this is not possible, then the default needs to be set to 0.
--
TWiki:Main.HaraldJoerg
I am about to prepare a fix (plus test cases) to ignore MinPasswordLength if either PasswordManager is 'none' or AllowLoginName is true. I deliberately do
not check for LoginManager because of the theoretical chance that a TWiki without own login manager allows to manage the password for a generally authenticated Apache htpasswd file.
--
TWiki:Main.HaraldJoerg
I originally set the MinpasswordLength to 0, but then got flak because the standard registration form could be used without providing a password, which was incompatible with the way twiki was previously shipped.
Your fix sounds very sensible, thank you.
CC
Changing this to closed, not a released bug.
--
SP