Item4688: Foswiki password, registration and login options should be correctly handled in the registration page, change password and reset password

after an IRC discussion, I was reminded that you can't set up your twiki to use login names, and allow users to set passwords. There is an assumption in TWikiRegistration that if you AllowLoginNames that you would also set the PasswordManager to none, use apache auth, and have all user management done somewhere else.

This is one of those places where we need to write out the matrix of options, and work out howto make them all possible.

THUS, this is a 4.2.1 or later issue, and will not be fixed in the 4.2.0 release

for eg, if you use an external auth management system (eg. you're adding twiki to an existing web site) and you want to use TemplateLogin, you must have PasswordManager (for templatelogin), but you also need to tell twiki to not write to the htpasswd file, etc.

-- TWiki:Main/SvenDowideit - 21 Sep 2007

Agree. Both on Sven's assessment and that is is a small fix to defer to next patch 4.2.1

-- TWiki:Main.KennethLavrsen - 21 Sep 2007

Analysis with Sven:

The TWikiRegistration, ResetPassword, and ChangePassword need to be depending on whether TWiki handles changing and creating password.

Only the Password Handler knows this.

The fix will be that these handlers set a context and an IF in the 3 pages can then...

• TWikiRegistration - the password field will only be visible when the context is true
• ResetPassword, and ChangePassword - will have conditional code so that the reset or change password form is only visible if this password handler context is true. Otherwise a generic text will say that setting and resetting of passwords is handled elsewhere. We may even create a setting where an admin can define a URL that these pages point to for resetting and changing passwords.

Target for this is 4.2.3

-- TWiki:Main.KennethLavrsen - 02 Aug 2008

Target is now 4.2.4

The action required is that someone helps finding the best way to introduce a context we can test for - for the password field. Ie let the password handler set a context if it handles passwords so we can test for is to decide if password field and reset/change password are displayed.

I can take care of the topics and the conditional code there as long as someone helps with the context code. If we do not get this closed within a week I will defer it to 5.0.

-- TWiki:Main.KennethLavrsen - 18 Sep 2008

Downgraded to normal after an IRC discussion with Kenneth.

-- CrawfordCurrie - 28 Nov 2008

A good discussion for this is found on Item965 which I have marked as a duplicate of this one.

We have been targetting this for patch releases before and I still think adding a context which is set by Foswiki::Users::HtPasswdUser and Foswiki::Users::ApacheHtpasswdUser is easy to implement and easy to test for.

And then at least make the password fields depending on the this. Also note that besides the 3 topics also registration emails must be considered. See Item965

Elevating this to urgent. I find we have deferred this so many times now that I will try and push for this going into 1.0.1.

-- KennethLavrsen - 09 Feb 2009

fixed duplicate LoginName: entry in email.

just found that the rego script seems to assume that the LoginName sent is valid and uses it, even if {AllowLoginName} = FALSE - when it should refuse to register unless LoginName = WikiName, or LoginName is unset.

so, if someone crafts their own rego form, they can break things.

-- SvenDowideit - 14 Feb 2009

To fix this one we need a new context variable which is set by the password manager IF it handles setting and resetting passwords.

Too risky in a 1.0.X context.

But if someone could add the context on trunk in a not too distant future I can take care of the topic updates that will take advantage of it.

All the context variable has to do is being set if the password manager handles passwords. Ie. the user is able to

• Set a password during registration
• Reset his password on ResetPassword
• Change his password on ChangePassword

By default this context variable should not be defined or not true and only if you use a password manager that does these things - the context is set.

This also needs to be done in the non-standard stuff like the LDAP contribs / plugins IF and only IF these handles setting passwords and it is not disabled by configuration.

-- KennethLavrsen - 16 Jun 2009

We already have the context which is called 'passwords_modifyable'

And in the UserRegistration topic it is a change of the %IF. So very simple change but very admin friendly. Especially for those that want to use standard Apache password protection but still use usernames different from WikiName. Adding this will remove the need to tailor UserRegistration for quite many admins.

-- KennethLavrsen - 26 Feb 2010

UserRegistration is now resolved.

I have sent an email to Michael about the Ldap password manager which lacks this 'passwords_modifyable' context.

My next step is the change and reset password pages.

They have today a message that says the change/reset is temporarily disabled. I think having such a message for the special case that the password file is readonly could be done more generally.

My plan is to eliminate the need to tailor ChangePassword and ResetPassword

My plan is to define this macro in DefaultPreferences

* Set CHANGEPASSWORDDISABLEDMESSAGE = Resetting and setting password is not possible from within Foswiki

The admin can then accept this or alter it in SitePreferences to something like

* Set CHANGEPASSWORDDISABLEDMESSAGE = To change or reset password please go to http://password.mycompany.com and follow the instructions

For us experienced admins changing this means 3 less topics to worry about when upgrading.

For the newbie admin it is 3 less steps to worry about when installing.

-- KennethLavrsen - 26 Feb 2010

I have implemented the change of ResetPassword and ChangePassword so you do not need to tailor these. Instead you can define CHANGEPASSWORDDISABLEDMESSAGE in SitePreferences to point to the URL where you change password on your single sign on site in the company.

Still need to modify ChangeEmailAddress which also needs its content to depend on 'passwords_modifyable' context.

I will do this.

-- KennethLavrsen - 15 Jul 2010

Feature is completed. Incl docu update.

This was the remaining item. UserRegistration is now possible to tailor without being overwritten when upgrading. ChangePassword and ResetPassword can now be tailored by a simple CHANGEPASSWORDDISABLEDMESSAGE preference setting and the default message is good enough for most. ChangeEmailAddress is now behaving according to password manager setting and does not need any tailoring at all.

Another important step towards easier installation, easier tailoring, and easier upgrading is completed.

-- KennethLavrsen - 19 Jul 2010