Last modified: 2012-03-14 20:18:22 UTC
I found that the right "passwordreset" does not prohibit the view of Special:PasswordReset - what the name suggests - but is a user right to view the Password-Reset-Mail including the temporary password. This appears to be disabled during installation but can be activated for example by using # allow admins to access view reset e-mails $wgGroupPermissions['sysop']['passwordreset'] = true; I suggest to globally change the name of the user permission and related system message keys from * passwordreset to passwordreset-view-reset-mail * right-passwordreset to right-passwordreset-view-reset-mail where it applies to avoid unintended revealing of password-reset-mails and contents in case that WikiSysops misinterprets this setting.
Attention translator: also the localised texts of "right-passwordreset" need to be checked. For example, the (current) German text is wrong 'right-passwordreset' => 'Passwort eines Benutzers zurücksetzen', I will change this now to 'right-passwordreset' => 'Kann Passwort eines Benutzers zurücksetzen und die dazu verschickte Passwort-Mail einsehen',
see also * Passwordreset-capture-* message texts.
After checking the message texts I came to the conclusion, that a rename to "passwordreset-emailsent-capture-view" respectively to "right-passwordreset-emailsent-capture-view" may be the best solution, because it functionally relates to already existing texts with "passwordreset-emailsent-capture-*" and "passwordreset-capture-*" as mentioned above. See * line 89 if( $this->getUser()->isAllowed( 'passwordreset' ) ) and other lines in http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/specials/SpecialPasswordReset.php?view=annotate
The following is just added for sake of completeness: see also r1=94932&r2=95596">http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/specials/SpecialPasswordReset.php?r1=94932&r2=95596 (reverted in r1=95596&r2=95618">http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/specials/SpecialPasswordReset.php?r1=95596&r2=95618 ) where I suggested the use of a (at this time) user right "resetpassword" for restricting the access to Special:PasswordReset to a certain group. (Rationale: I needed that for certain configurations of OpenID-enabled Wikis, where only log-ins with OpenID are allows $wgOpenIDOnly = true ; Such a use however is not mainstream use of MediaWiki, and the commit was therefore reverted by myself.)
Other than that it is not very intuitively named, is there a pressing need to make such a breaking change?
(In reply to comment #5) > Other than that it is not very intuitively named, is there a pressing need to > make such a breaking change? Pls. change the title, if you have a better proposal. It's always difficult to please everyone. At least I always try to express in the title not only the area a bug belongs to, but also the content. I will try harder... I think, that the mentioned parameter name is not reflecting what it really stands for, which can be a risk if someone uses it. Because we have other names with "email*captured*" in it, I thought, it should be harmonised. It is certainly not urgent.
(In reply to comment #6) > (In reply to comment #5) > > Other than that it is not very intuitively named, is there a pressing need to > > make such a breaking change? > > Pls. change the title, if you have a better proposal. It's always difficult to > please everyone. At least I always try to express in the title not only the > area a bug belongs to, but also the content. I will try harder... > > I think, that the mentioned parameter name is not reflecting what it really > stands for, which can be a risk if someone uses it. Because we have other names > with "email*captured*" in it, I thought, it should be harmonised. You misunderstand, I'm not talking about the bug title (which excellently describes the proposed change) but the change itself. Changing the permission to *anything* other than what it currently is is a breaking change that will require sysadmins to update their configurations, or cause friction between them and their users if they forget to do so. As such, it should only be done if there is a pressing need for it. Given that the permission key name is only ever exposed accompanied by either documentation or an explanation of what it does, I don't think such a pressure exists.
Oh yes, I misunderstood you. BTW, I do have the same concerns and just wanted to mention the problem with the name. I don't know, if this bug should be closed as RESOLVED WONTFIX - because it has now been discussed broadly; (I would agree with such a bug status change.)
RESO WONT as withdrawn by requester. Remove irrelevant see also link.
