My deployment requires that users be able to reset forgotten passwords without having to email an administrator.
I've made the necessary changes to generate a random password and email it to the address specified in the user's home topic. To stop people resetting each other's passwords, I've had to make the home topics writable by only the owner (otherwise you can change a person's email address and have the system mail you a new password).
Is this something that should be incorporated into TWiki? If so, here are a few questions that need answering:
- I've overwritten the ResetPassword topic to perform this function. Can the existing "mail the admin" method co-exist? If so, how?
- All home topics now need to be only owner-writable for security reasons. How can this be enforced? What about Wiki's without authentication?
- At the moment, random passwords are generated with the binary pwgen from http://www.sourceforge.net/projects/pwgen. Do we need a Perl version?
All necessary changes are attached and were made against the Beijing release.
- 06 Mar 2003
This is very close to a killer tool for TWiki, thanks for writing this
is mentioned by people where I work as a key reason for not using TWiki, so this is very useful! Wikis without authentication probably don't care about resetting passwords, so I think the 'home page non-writeable' is not a bad idea - can be handled via the home page template I think. And this is so much nicer than 'mail the admin' that I wouldn't mind deprecating that method if this makes it into the core. Others might disagree though.
Don't have time to look at this right now, but a Perl version of pwgen would be useful, and probably not that hard. See also EmailResetPassword
- 06 Mar 2003
Nice enhancement, I vote to add it to the core. ForgettingPasswords
is real problem for us, and most other systems allow to handle this common problem without manual handling by admin. So Twiki's handling is a quirk, not a feature. RuleOne
Also, IMHO personal homepage (like PeterMasiar
) should be writable only by user, even if resetting password is rejected. What might be a reason to allow somebody else to change my homepage? I do not see any...
- 07 Mar 2003
Writing a note on someone else's home page was (is??) fairly common on the C2 wiki, so it should not be ruled out as a possibility. Of course, there is a difference on TWiki -- on the C2 wiki there was only one "web" so all changes showed up in a common list -- if you saw that your page was changed (not by you, especially) you'd go and take a look. I personaly hardly ever look at the main web for changes, and we seem to do a good job of dialogue on each page. Hmm, maybe it is not worth preserving?
- 07 Mar 2003
I personaly never thought about editing somebody else's homepage. I assumed that if a persom wants to be contacted, provides email. From couple thousands
registered users, only about a dozen subscribed to changes on Main.WebNotify
and will notice this kind of message. Most other users will never (or only by chance) notice it.
So let's consider Twiki's feature: allow to edit somebody else's homepage
- Do we want to keep it for backward compatibility, though hardly anybody uses it,
- Or change it to allow new feature ResetPasswordByEmail, which most major competing product have, and many user are asking for, and we know is a big issue for improving usability?
Let's see what CoreTeam
members think about it.
- 08 Mar 2003
If anyone uses this and gets emails that don't have the password, add a line between the two following lines in mailresetpassword.tmpl:
Subject: TWiki password reset for %WIKINAME%
Your password has been changed to "%PASSWORD%".
: Updated attachment as suggested - found that the problem occurs when mail is sent via M$ Exchange
You may also need to change the path for 'pwgen' in passwd or create a symbolic link. The executable is listed as './pwgen' but a default install of pwgen from source will install the file in '/usr/local/bin/pwgen'.
Hope this helps.
- 10 Mar 2003
I think setting the default to be readonly for the world is sensible. The user can easily change this if they wish by editing one line.
Don't confuse typical TWiki.org usage with potential as-deployed usage. Consider the scenario where users' home pages are used as blogs rather than simply a personal preferences page.
- 10 Mar 2003
I've deleted the sarcastic comment about release timelines and Randy's response - while frustration at the delay in releases is quite understandable, the sarcasm and anonymity is not really helpful. A similar comment is still on CairoRelease
if people want to respond to this, please followup there if needed.
- 20 Mar 2003
Thanks for building this Graeme.
A couple of comments:
- The patches would be more easily applied if they were generated from the TWIKIBASE directory and hence included templates/, data/ and bin/ in the output. (CoreTeam - have we standardised on this, I think we ought to.)
- I noticed that if you install the patch but don't install pwgen using resetpassword deletes the password! Furthermore it does not write anything in the debug.txt or warning.txt files. Perhaps it should?!
- Where, as an end user on a shared webhosted platform should I put the binary pwgen file if my system admins are unwilling to install it for everyone?
Thanks again. This is very useful to me because I want to preregister a whole bunch of people. This way I can do so and so, along with their welcome email, I can include the link to the Change Password page.
- 30 Mar 2003
As for a perl implementation of pwgen, check this out:
Perhaps Graeme would care to do another version using this and then we can get it into CairoRelease
- 30 Mar 2003
The guidelines for patches are at PatchGuidelines
- please comment there on standardising on TWiki base directory as root of patches, as this would be a good idea. Patches based on these guidelines would make it easier to review and apply them.
- 02 Apr 2003
I implemented functionality to email the owner of an account with a new, random, password as part of my RegisterCgiScriptRewrite
. This is now part of DevelopBranch
, scheduled for DakarRelease
- 19 Feb 2005