Extension talk:Password Reset/LQT Archive 1

Rights
Maybe it is better to replace the 'userrights' with e.g. 'resetpassword' because with $wgRemoveGroups and $wgAddGroups it is possible that users who should not have access to Special:PasswordReset, can have access to it. SPQRobin 11:31, 3 November 2007 (UTC)
 * I opened bug 11914 SPQRobin 22:26, 9 November 2007 (UTC)
 * Yeah, but I despise non-standard permissions.
 * Thanks for fixing it. I had also seen the extension uses wfMsgForContent, but I think that's useless because there are translations. I changed it in the my second comment in the bug, but you haven't seen it I guess. Do you want to change it to wfMsg? Thanks, SPQRobin 21:14, 19 November 2007 (UTC)
 * The difference between wfMsg and wfMsgForContent is *which* language setting it translates to, wfMsgForContent does not change depending on the user's language prefererences, while wfMsg does change based on the user's language. It's still translating.  It just doesn't care what the User Preference is set to.
 * Yes, I know, but why should it use the site language and not the user language, if there are translations? SPQRobin 16:59, 20 November 2007 (UTC)
 * Because it's an admin page. Where on earth do we have site administrators that don't understand the default site language?  Though I suppose your argument is within the lines of "it wouldn't hurt," eh?
 * Yes :-) If you see really everything translated, but only this extension not... SPQRobin 18:39, 20 November 2007 (UTC)
 * Done in r27718.

Question

 * Could you add a checkbox to disable a user on your Special Page ?
 * It will make the password field be updated to ' * ', but without salting it, making it impossible for a user to ever match the password
 * Well, the user could always request a randomized password via email - Which could be diabled, I suppose.

Answer

 * What's wrong w/ the current blocking functionality in MW? I don't think there's any chance of a mainstream user 'guessing' 16 random characters either - wouldn't that be equally effective?  ;-)  Tim Laqua talk 14:15, 7 December 2007 (UTC)

Question 2

 * The current blocking feature blocks from editing, not login. We have a wiki install that requires login to even read, so user administration is essential.
 * We do effectively enter manually a random password for now, but this would be easier and completely failsafe.--Y.combarnous 15:27, 7 December 2007 (UTC)

Implemented

 * Implemented in r28251. Let me know if you notice any bugs w/ the new functionality.  Tim Laqua talk 18:06, 7 December 2007 (UTC)

Observation
Tim Laqua talk 08:22, 13 December 2007 (UTC)
 * I love the "disable" feature, however it would be great for it to also disable the "by email" feature. At the moment preventing a user from viewing a Wiki involves two steps: Using BlockUser to prevent the user from sending emails, and using PasswordReset to disable logins. - 149.171.89.39 07:12, 12 December 2007 (UTC)
 * Disabling their email so they can't reset their own password via email? Is that what you're referring to?  Tim Laqua talk 12:41, 12 December 2007 (UTC)
 * Yep, that's what I mean. - 149.171.89.39 00:05, 13 December 2007 (UTC)
 * Implemented blocking hook in r28418. Tim Laqua talk 20:21, 12 December 2007 (UTC)
 * I just tried r28418 and it still allows password reset by email... - 149.171.89.39 00:10, 13 December 2007 (UTC)
 * Please grab the current SVN revision, I removed some debug code from r28418.
 * Also, note that it only blocks users that have been disabled using the Disable User Account checkbox (which sets the user_password hash to "DISABLED").
 * What version of MediaWiki are you running and what is your default language? Tim Laqua talk 01:12, 13 December 2007 (UTC)
 * Thanks for working on this. I've grabbed the latest SVN revision. I'm running Mediawiki 1.11.0, and my language is English. I go to Special:PasswordReset, enter a username, select the Disable User Account? checkbox, then click "Reset Password". The disabled user is still able to reset their password with the "by email" button. - 149.171.89.39 06:21, 13 December 2007 (UTC)
 * That's pretty odd. I tested on 1.10.2, 1.11.0, and 1.12alpha (r25309) - works as expected.
 *  What database are you using?
 *  If you go to Special:Version in your wiki, scroll to the bottom in the Hooks section - do you see "GetBlockedStatus" Subscribed by "PasswordReset::GetBlockedStatus" ?
 *  What other extensions are you running and is PasswordReset the first or last extension to be included in LocalSettings.php?
 *  Do any of your other currently installed extensions Subscribe to "GetBlockedStatus" ?
 * In the case that you have other blocking extensions, try putting PasswordReset after all the other extensions in LocalSettings.php (if that doesn't work, give me the name of the exensions and I'll figure it out)
 * Tim Laqua talk 08:13, 13 December 2007 (UTC)
 * UPDATE - grab the SVN version again - r28436 defines the hook a little differently. Now, putting PasswordReset after the other extensions in LocalSettings.php really should resolve the problem if it's related to timing.
 * I'm having the same problem as the user above... when I check the "Disable User Account" box, the user is still able to reset their password by email. I'm running the latest version of PasswordReset on Mediawiki 1.11.0, PHP 5.2.3, MySQL 5.0.41 on Win2003. I'm running these extensions: Inputbox, ParserFunctions, and SemanticMediawiki. PasswordReset is the last extension in LocalSettings.php. GetBlockedStatus is subscribed by PasswordReset and no other extension. - Borofkin 00:18, 31 January 2008 (UTC)
 * Could you try logging in to the Wiki using one browser (like FireFox) as a test user, then logging in to the Wiki as an admin with another browser (like IE). Then disable the Test user.  Then, as the Test user, attempt to edit a page.  The test user should be forcefully be logged out and redirected to the main page.  I'm trying to see if the hook isn't firing or if the problem is with the mailing logic (alternatively, I can just corrupt the user's email address by adding .DISABLED to the end of it or something) Tim Laqua talk 17:52, 31 January 2008 (UTC)
 * Try the new version (1.5, r30353) - I switched from a DB query to initalizing a User object to get the password hash. Let me know if that works properly.  Tim Laqua talk 18:47, 31 January 2008 (UTC)

Bug report: several undefined PHP variables

 * PHP Notice: Undefined variable: newpass in mediawiki\\extensions\\PasswordReset\\PasswordReset_body.php on line 86
 * PHP Notice: Undefined variable: confirmpass in mediawiki\\extensions\\PasswordReset\\PasswordReset_body.php on line 91
 * PHP Notice: Undefined variable: validUser in mediawiki\\extensions\\PasswordReset\\PasswordReset_body.php on line 97
 * --Y.combarnous 15:27, 7 December 2007 (UTC)
 * Fixed in r28249. Tim Laqua talk 16:24, 7 December 2007 (UTC)

enhancement - email password
It may be useful to enter an email address, so the system can generate a new password and email it; like the normal password reset for accounts that don't have an email address stored in the system. -Steve Sanbeg 17:54, 21 December 2007 (UTC)
 * I'm not sure I like the idea. Setting a temp password for a user and asking them to change their password forces the user to understand how to change their password and helps them understand why it's a good idea to have a registered email address (so they can reset themselves). Tim Laqua talk 23:08, 21 December 2007 (UTC)
 * I'm sorry, I don't understand this. You say you're not sure you like the idea, but it is a good idea?  I agree with the second sentence, but AFAIK the extension doesn't currently allow that. -Steve Sanbeg 20:54, 2 January 2008 (UTC)