Using the ChangeEmailAddress page, anyone can change the email address for guest by entering "guest" for the username, no password, and any email address.

"guest"'s email address should be immutable, and either invalid, or point to the site's administrator email address.

-- TWiki:Main.JoanTouzet

TWikiGuest should not have an email address and should not be allowed to change password.

ResetPasswords should refuce the TWikiGuest as argument and ChangePasswords should refuse TWikiGuest´to run it.

Or rather the user defined by {DefaultUserWikiName} or {DefaultUserLogin} should not be allowed to change password or email address.

KJL

Sorry about that, temporary glitch. Well spotted. Please check that the problem has gone (SVN 8444)

CC

Tested a bit.

If there is no TWikiGuest or guest defined in .htaccess - there is no problem

If you want TWikiGuest to be able to edit topics - and add a password (e.g. "guest") to .htpasswd for TWikiGuest but not guest you cannot ResetPassword for neither TWikiGuest nor guest. Somehow the ChangeEmailAddress function uses the TWikiUsers linking from WikiName to login name (even when login name is disabled) and then fails to let the TWikiGuest authenticate to change password.

I have not tried to enable login name. And I have not tried to make an additional 'guest' entry in the .htaccess file. I have the feeling that if I do that we still have the problem that TWikiGuest can change his email address.

A public TWiki will normally not have special login names so it is not a very big problem as it is now but it may not be very well controlled and predictable either.

KJL

CC

I just tried it, and the behaviour is exactly what I'd expect. It is modelled on the password change interface, and has the same constraints and limitations. AFAICT, it is not possible to change the guest email unless you know the guest password (the one stored in htpasswd).

If you need something else, then we will need to make the default password manager smarter; able to store emails in home topics.

Discarded (though the points were well made and are still being thought about)

CC