Item965: {Register}{HidePassword} = $FALSE; not respected when the password is generated by Register.pm

When $Foswiki::cfg{Register}{AllowLoginName} = 1; is set in the configuration, the Registration page omits the password fields. In addition, the configuration setting {Register}{HidePasswd} is enabled and hidden, so it is not obvious to the new admin that it needs to be enabled or registered users have no means of setting or learning their passwords.

There also seems to be an issue with {Register}{HidePasswd}. When $Foswiki::cfg{Register}{AllowLoginName} = 1; is set in the configuration, the password is not only omitted from the registration page, but also from the registration e-mail. This leaves resetting the password as the only way to gain access to the account that was just created, otherwise the user is locked out of their own account.

Suggest that rather than assuming that Registration should not permit entry of a password, add a configuration parameter - AllowRegistrationPassword should permit the admin to control whether users can enter a password independent of the login name setting.

This also reflects on a bigger documentation problem - the settings are "internally" focused instead of admin task focused,

This is an assumption hard-coded in the registration page:

# optional rows for password, enabled by {Register}{AllowLoginName} option in =configure=, we assume that login name means that Foswiki does not handle passwords.

It appears that the htPassword manager does correctly handle registration of login names.

I've locally tested a simple fix.

• Added new configure setting: $Foswiki::cfg{Register}{EnableRegistrationPassword} = 1;
• Modified registration page: %IF{"{Register}{EnableRegistrationPassword}" then="%BESPOKE_PASSWORD%"}%

However, I'm wondering if a move comprehensive fix would be to allow the Password Manager to set a context variable if it supports setting passwords, and modify Users.pm to set the context if the password manager supports the function, and the configuration allows it to be enabled. Also if the parameter, is not specified, it should default to true/false depending upon the AllowLoginName parameter

-- GeorgeClark

I think we should look at the need to make a quick fix for 1.0.1 that does send out a password, and then review it properly for 1.1.

IF I have time for the quick fix, I'll make that a new bug and re-grade this to normal. Til it is acted on (or 1.0.1 is released, setting this to urgent)

-- SvenDowideit - 08 Feb 2009

In considering the ease of change of the Registration panel as a very simple workaround, it seems like this could be handled in documentation until a more thorough fix is worked out. It appears that password handling is fully functional if the register topic is modified to expose the password field. It's probably a reasonably safe assumption that in most cases, when using a login-name from the underlying OS or some other source, that Foswiki would typically not have to manage the passwords. I don't think it's worth blocking the release for this one.

-- GeorgeClark - 08 Feb 2009

What is worth highlighting for the release (if someone has time for it), is that with AllowLoginName, we don't send out the password in the rego email - even when we 'tick that setting'.

And I think this is the case atm -

-- SvenDowideit - 08 Feb 2009

With the modified registration page where password can be entered, and hidePassword NOT ticked, then the password was included in the e-mail to the registered user, and *** in the admin version. I tested with Foswiki 1.0.0. I then put the UserRegistration topic back to default and registered again. With no password entered on the form, the email is missing the password field completely. Not just masked, but no field. Here is what I've observed when Allow Login Name is enabled:

Hide password set, Default UserRegistration

No password field on Reg. form. The user receives an email with a masked password ******

Hide password set, Modified UserRegistration

User receives email with masked password, but will know password because they entered it on the registration form.

Hide password NOT set, Default UserRegistration

User received email with no password field present.

Hide password NOT set, Modified UserRegistration

User receives email with password disclosed.

-- GeorgeClark - 09 Feb 2009

Man George, You're making it simple

I see

Hide password NOT set, Default UserRegistration

User received email with no password field present.

as the urgent bug, as its seems to have caused confusion for a few people (that have talked to me about it) and the rest as 1.1 work

-- SvenDowideit - 09 Feb 2009

If you have Allow Login Name enabled, we have so far assumed that it is not Foswiki that handles passwords.

It makes very little sense that someone would want to have one login name and another wikiname on a wiki. It is more obvious to login with the wikiname.

I can see one example, where you want Foswiki to actually be the password manager for ID's used by another application. It will permit Foswiki to maintain the .htpasswd file for a "login name" that may be in common with other web applications that might need to support a more unix-like userid instead of the WikiName.

It reverses the model a bit. Instead of the outside application managing the login name / password, it uses it, and Foswiki manages it.

Except in the many many cases where you already have a login name and a password common across many applications and platforms. Often a single sign on thing where the login for the Windows domain is used to authenticate all sorts of web based applications.

Or another very popular one is LDAP authentication where a corporation uses an LDAP server to authenticate most anything. And where I work it is both. Windows domain passwords get synced to the LDAP server by the user through a web based application.

All these schemes have this in common

• Foswiki has no clue what your password is. Not even when you register
• You cannot reset or change your password through Foswiki. All password handling happens elsewhere
• You do not need to give a password when you register. It is common that a new employee gets registered by someone else - like a department assistant

So what about this registration email and passwords?

The registration email should not mention a single word about passwords unless Foswiki handles passwords. It is only confusing if you get an email with an empty field, or password replaced by 8 time *. The correct display is no display in this case.

On the registration page we have assumed that having a login name means that Foswiki does not handle passwords. It matches the reality in 95-99% of the cases (qualified guess figure). But still leaves behind some 1-5%. And it is about time we do something about it.

We have discussed this before the fork and we actually agreed Sven and I on how to. And then the many other things that happended took priority.

But the right way is to let the selected {PasswordManager} in configure that should control both if password field is visible on the registration page and if it is present in the registration email.

{Register}{HidePasswd} should only have any effect when the {PasswordManager} is one where Foswiki handles creating/changing passwords. And should be documented as such.

We cannot know which {PasswordManagers} that exists out there. But we can at least handle the ones we have in our distribution and in known extensions on Foswiki trunk.

In my view we should add a context variable that could be called "FoswikiPasswordManagement" to the two default managers that we ship in a not so distant future.

Having such a context variable we can

• On the registration page we make the password fields visible only when this context is true.
• On ResetPassword and ChangePassword we put two versions of content. One is todays which is shown if the context FoswikiPasswordManagement is true. And the other is a generic text which we should consider making easy for the admin to define in a way that does not later get overwritten. The admin will typically want to put a short message that points to the password change website of the company.
• On the registration email the password field is only included if a password was actually submitted. And how it is displayed is then given by {Register}{HidePasswd}.

It is very risky to take on one of these tasks for 1.0.1.

We already have a bug item for this. It is Item4688. So I will no action this one - but since this one contains good info I will reference this one from Item4688.

-- KennethLavrsen - 09 Feb 2009

It makes very little sense that someone would want to have one login name and another wikiname on a wiki. It is more obvious to login with the wikiname.

is simply untrue. I've been asked to set things up this way many times - twice in the last week even. Generally when Foswiki is managing its own users, but the desire is that the usernames are something that the users use commonly, and remember.

Kenneth is describing the case where PasswordManager = "none", and AllowLogin is true, however there are users that intentionally have a password manager and set AllowLogin - and for those we need to respect HidePassord.

and given that your initial premise is incorrect, and that fixing this one aspect is actually pretty simple - ie, when there is a password sent from the register form, obey the HidePassword setting, I dissagree that this cannot be done for 1.0.1.

NOTE that I am not proposing to change the Registration topic, that I leave for post 1.0.1, only to fix the {HidePassword} so that it works right.

-- SvenDowideit - 09 Feb 2009

I should also been quoted for

On the registration page we have assumed that having a login name means that Foswiki does not handle passwords. It matches the reality in 95-99% of the cases (qualified guess figure). But still leaves behind some 1-5%. And it is about time we do something about it.

But the thing we should do about it is the right thing and not another terrible patching

-- KennethLavrsen - 12 Feb 2009

ah Kenneth, if you're going to write something where you say 'it makes no sense' and then several paragraphs later 'it does make sense' then you are going to confuse me and some other readers.

nm, I've fixed the bug where we hide the password even though the admin expects it to be non-hidden. The rest of the work is for Item4688

-- SvenDowideit - 14 Feb 2009