Extension talk:Password Reset/LQT Archive 1

=2007=

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.

Questions

 * 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)
 * Hi Tim... yep, version 1.5 works for me. When the blocked user attempts to send an email, it produces the error "Login error: Your IP address is blocked from editing, and so is not allowed to use the password recovery function to prevent abuse." Perfect! This is a supremely useful extension. - Borofkin 06:36, 4 February 2008 (UTC)
 * This seems to have broken in r35923. Since the password field for disabled users is no longer set to "DISABLED", I'm able to request new passwords by email. The SQL query in PasswordReset_Disabledusers.php won't find any newly disabled users, either. 63.126.183.106 20:22, 24 June 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)
 * That's the manual workflow for resets. It's not automatic.  Tim Laqua talk 18:02, 5 February 2008 (UTC)

=2008=

Disabled users list NO longer working (December 2008)
--198.103.53.5 16:18, 18 November 2008 (UTC)

There may be a bug in your software (or maybe how I've installed it)

the code you use to create the Disabled Users list

"SELECT 'Disabledusers' as type, 	user_id, 	user_name as value FROM $user WHERE user_password='DISABLED'";

I think should be "SELECT 'Disabledusers' as type, 	user_id, 	user_name as value FROM $user WHERE user_password=''";

Since you set your password to "null" in he PasswordReset_body.php file.

Am I wrong?

--83.247.29.30 17:10, 10 December 2008 (UTC) Yes I think you are right, I experience this also: and  are NOT compatible anymore. sets a password to null in case of disabling an account,  is quering for "DISABLED". So there will never be a hit. Your suggested change fixes this. This error seems to have been introduced as of revision 35923 to.

Block list
Okay, another question... with version 1.5, blocked users don't appear in Special:Ipblocklist. Is this correct? - Borofkin 06:40, 4 February 2008 (UTC)
 * Yes, that is correct - Ipblocklist is a list of records in the ipblocks table - disabled users are not blocked so much as "disabled." Which means that their user.user_password has been set to "DISABLED" - to re-enable a user, you reset their password using PasswordReset.  The user does receive an ipblock type message if they try to email themselves, but this is simply a result of the blocking methodology the extension has to use to prohibit use of the system.  For the particular hook i'm using (which is the only hook that can be used at this stage of the login process), there isn't a good way to throw a custom message in there.  Up to this point, I haven't worried about getting a list of disabled users...  Do we really need one?  To get the list of disabled users, you can run the following SQL query: SELECT user_id, user_name FROM user WHERE user_password='DISABLED'; Tim Laqua talk 14:21, 4 February 2008 (UTC)
 * I'm using the extension for user management on a corporate wiki. As users leave the company, their access (both edit and read) needs to be disabled, and it is useful to be able to see which accounts have been disabled and which haven't. The SQL query achieves this goal, however the ultimate would be to have an equivalent of Special:Listusers which showed all accounts, with disabled accounts marked as such. - Borofkin 01:02, 5 February 2008 (UTC)
 * Corporate, eh? Sounds like you guys need an in-house MW dev!  *hint*  I'll take a look at a Blocklist clone.  Tim Laqua talk 18:01, 5 February 2008 (UTC)
 * Implemented in v1.6, r30588 - please let me know if you encounter any issues. Tim Laqua talk 20:43, 5 February 2008 (UTC)

No longer working?
Hi... seems like the extension doesn't work on my wiki, but it should be, from what I can see...

Normally, I'd google "mediawiki password reset", and follow the instructions there, but for some reason, those SQL commands no longer work... only thing that's changed in my installation is that I'm using the most up-to-date version of mediawiki?? Kareeser|Talk! 21:02, 10 March 2008 (UTC)
 * I probably haven't given you nearly enough info, so I'll help by providing what you need. I'll check back periodically. Kareeser|Talk! 21:07, 10 March 2008 (UTC)
 * "Those SQL commands no longer work?" ;-)  What exactly did you change w/ your Wiki and do you have a public URL?  The MW password hashing methodology hasn't changed afaik.  Did you possibly change the value of $wgPasswordSalt?  It's a boolean variable - if it's true, the encryption is as follows:

md5("{$userid}-" . md5($password))
 * If $wgPasswordSalt is false, the encyrption is:

md5($password) The url of the wiki: http://sesdb.kareeser.com I'm using "short URLs", if that makes any difference? Kareeser|Talk! 15:04, 12 March 2008 (UTC)
 * But honestly, i've never seen $wgPasswordSalt set to false</tt>. I suspect something else is amiss in your Wiki install so if you can fill me in on what you used to have setup and what you changed, I can try to help.  Tim Laqua talk 01:04, 11 March 2008 (UTC)
 * Thanks for your help! I've taken a look in my LocalSettings.php, and ran a search for "wgPasswordSalt", which came up empty-handed, so I assume it's not set at all, which might mean it's off? I've tried changing passwords manually using the method without the salt, but it still doesn't work either, which is odd. Perhaps I mistyped something?
 * And DefaultSettings.php has the value set to true, which is only logical, since I never edited that file :) Kareeser|Talk! 15:06, 12 March 2008 (UTC)
 * As for changes in my installation:
 * Disabling edits and registrations for anonymous users ($wgGroupPermissions)
 * Short URLs
 * ParserFunctions
 * Allowing GIF files ($wgFileExtensions)
 * Allowing external images (only to make work...)
 * $wgServer (since I'm on a subdomain &mdash; not sure if I used this right...?)
 * ... and of course, the mandatory code for the PasswordReset Script.
 * The only two directories in the extensions dir are ParserFunctions and PasswordReset.
 * One problem I did notice when attempting to install this extension was that I couldn't use "wget" to directly get the files from the addresses linked on the extension home page. Instead of downloading the php file, it downloaded the HTML output (I think)... Kareeser|Talk! 15:12, 12 March 2008 (UTC)
 * What exactly is the problem? Can you get to the PassswordReset special page and reset the password, but you can't login?  And if you 'reset' a password, does it change the password, but just improperly?  LIke take an account w/ a password that you know like "password1" then use PasswordReset to change it to "password2" - then can you login using password1 or password2?  Tim Laqua talk 16:30, 12 March 2008 (UTC)
 * Script seems to work fine, but the changed password doesn't work as a login, so I'm going to fathom that it just changed the password improperly... Kareeser|Talk! 02:38, 13 March 2008 (UTC)
 * Do you have access to the SQL database? If you do, can you check the user_password field for that user after you reset their password?  Is it set to a MD5 hash?  or blank?  Or possibly "DISABLED" ?  Tim Laqua talk 11:08, 13 March 2008 (UTC)
 * Mm... I do, but the password field is set to "blob" (as I can recall), and the hash isn't viewable, as far as I know... It is viewable in the SQL dump, however. I'll give it a try later today. Kareeser|Talk! 12:31, 15 March 2008 (UTC)

Stewards
Hi, I'm a steward on a project.. But is it for sysops also possible to change my password, or even disable my account? Untill I know the answer on this question I've set this permission off for sysops, it can now only be used by bureaucrats and stewards. 81.205.35.85 17:44, 15 March 2008 (UTC)
 * Correct - the extension does not make any checks for the group membership of the user being reset. If they can reset one person, they can reset everyone - including themselves.  Tim Laqua talk 22:31, 16 March 2008 (UTC)

Error
Why am I getting this error on the header of my wiki now Warning: call_user_func_array [function.call-user-func-array]: Unable to call PasswordReset::GetBlockedStatus in /opt/mediawiki-1.9.3/includes/Hooks.php on line 114 -- 16 April 2008 Tim Laqua talk 02:10, 17 April 2008 (UTC)
 * Use v1.2.1 of the extension - no user Disable functionality. If you want the new version, upgrade your MW install to 1.12.  http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/PasswordReset/?pathrev=27718

Change in the extension description
It would be nice if you would say the exact MediaWiki page. It is not "Password reset" or "Disabled users", it is: --199.243.65.6 14:13, 2 June 2008 (UTC)
 * Special:PasswordReset
 * Special:Disabledusers

PasswordReset doesn't show on specialpages
I'm having trouble with PasswordReset. Although it's installed right, PasswordReminder doesn't show off on specialpages (I'm logged on as Sysop). I'm using MediaWiki 1.68 on a local webserver. I'm having the same problems with UserMerge. I would be very glad, if you could help me. --13 June 2008

Very useful!
Great little extension, will save a bunch of time. Cheers! Juux 08:56, 16 July 2008 (UTC)

See in special pages but get Error message
I think installation is fine and I can see the two new special pages but when I hit the link for Passage reset page I get the following error message: "The action you have requested is limited to users in the group Sysops." even though I am logged on as sysop. Any help?


 * I do have the same problem. Any support would be appreciated. D.Heindorf 217.194.34.103 10:51, 15 August 2008 (UTC)


 * same for me. --93.132.241.171 13:35, 15 August 2008 (UTC)


 * same for me too. --Hamsterham 08:07, 16 August 2008 (UTC)


 * same problem here, any ideas on a resolution? -RW 1308:081808


 * Ditto for me - any idea how to fix this? - CJ 25 August 2008


 * I'm getting the same error when using MediaWiki 1.13 while on my 1.12 installation the PasswordReset extension works fine. --Till Kraemer 17:17, 31 August 2008 (UTC)

I've fixed this is 40990. for some reason, in recent versions you need to have both the passwordreset and passwordresetself rights; they were checked as a pair, so having one right did nothing. -Steve Sanbeg 16:27, 18 September 2008 (UTC)

Confusion...
Does this extension allow a user to reset his/her password? I don't understand the typical 'use case' - I am getting confused by the thing about the sysop. --Dmb 17:19, 30 July 2008 (UTC)

Group Permission Confusion...
Just upgraded to MediaWiki 1.3 and installed Password Reset extension. My username is a part of the sysop group, but I can't view Password Reset page. Password Reset link is listed under Special Pages. When I click on link, it tells me that "The action you have requested is limited to users in the group sysop," which I'm a part of. Any suggestions? Disable Users appears to be working. It tells my that there is no report to display, assuming because I haven't been able to get to Password Reset. Thanks in advance for your assistance. -E. McCown 12:56:081908


 * I'm getting the same thing. I've had MediaWiki running fine for some time, but just installed PasswordReset, and my Sysop users are getting the error described above.  (MediaWiki: 1.11.0; PHP: 5.2.6 (cgi-fcgi); MySQL: 4.1.16-standard-log.)  Anyone have any ideas? -- wscott, 19:37, 21 August 2008 (UTC)


 * I get the same thing but I managed to change things in the file to fix this issue(I already let Tim know) - Andrew 22/08/2008 4:50pm NZ


 * He Andrew, unless Tim told you he'll release a new version in the next few days can you post what changes you made to make it work. We could use that in the meantmie. I could poke around in the PHP but that would take me a while (if I figure it out) THANKS - Marz2k 17:11, 22 August 2008 (UTC)


 * I'm not a php guru, but it seems part of the problem is found in /extensions/PasswordReset/PasswordReset_body.php:

if ( !$wgUser->isAllowed( 'passwordreset' ) || !$wgUser->isAllowed( 'passwordresetself' ) ) { $wgOut->permissionRequired( 'passwordreset' ); return; }

The permission 'passwordresetself' is not asigned to a group in localsettings.php. After commenting out the check for 'passwordresetself' (below), I was able to use the reset page. if ( !$wgUser->isAllowed( 'passwordreset' )) {// || !$wgUser->isAllowed ( 'passwordresetself' ) ) { 			$wgOut->permissionRequired( 'passwordreset' ); 			return; 		} I hope this helps anyone seeing this problem until the fix is released. jdoan 12:00 MDT 2AUG2008


 * Hi, I'm also not a php specialist, but after reading the comment above, I figured out that it also works to just add the line

$wgGroupPermissions['sysop']['passwordresetself']  = true; Nevertheless, thanks for the help! Hagen1980, 23:30, 2008-09-08

Fixing this extension (september 2008 - mediawiki 1.13.1)
I needed to make a few changes before this extension could work. --CrazyTerabyte 22:10, 15 September 2008 (UTC) Tim Laqua talk 00:07, 16 September 2008 (UTC)
 * The only change that should be required is the first diff where you removed the 'passwordresetself' condition - I have no idea where that came from. The rest of the changes will break LDAP auth or any other external auth that leaves the password field blank.  I'll get that permission switch made in SVN when I get a chance. Tim Laqua talk 23:24, 15 September 2008 (UTC)
 * Oop, scratch that. tstarling got rid of the DISABLED thing and is setting it to NULL instead (I haven't had a chance to test how it works now).  I don't know if the disable part works right now.  :-(
 * Right now, as I checked at the database (using phpmyadmin) and read somewhere in MediaWiki documentation, a NULL password field does mean the password is invalid and, thus, the user cannot login.
 * As far as I've tested it, my changes make the extension work (I could not login, I could not get a new password by e-mail, the username did show up at that disabled users page). Oh, since I don't use LDAP, I don't know how LDAP will work (or not work) with this.
 * Thanks for taking a look at this. --CrazyTerabyte 00:32, 16 September 2008 (UTC)

Error Messages (November 12 2008)
We recently updated our MediaWiki installation from 1.12.0 to 1.13.2, and the Password Reset extension (version 1.7) now causes the following diagnostics to be displayed following its installation:

Aliases file does not exist Backtrace:
 * 1) 0 /usr/local/apache2/htdocs/wiki/includes/SpecialPage.php(572): Language->getSpecialPageAliases
 * 2) 1 /usr/local/apache2/htdocs/wiki/includes/SpecialPage.php(586): SpecialPage::getLocalNameFor('Recentchanges', false)
 * 3) 2 /usr/local/apache2/htdocs/wiki/includes/OutputPage.php(1451): SpecialPage::getTitleFor('Recentchanges')
 * 4) 3 /usr/local/apache2/htdocs/wiki/includes/SkinTemplate.php(243): OutputPage->getHeadLinks
 * 5) 4 /usr/local/apache2/htdocs/wiki/includes/OutputPage.php(821): SkinTemplate->outputPage(Object(OutputPage))
 * 6) 5 /usr/local/apache2/htdocs/wiki/includes/Wiki.php(337): OutputPage->output
 * 7) 6 /usr/local/apache2/htdocs/wiki/index.php(94): MediaWiki->finalCleanup(Array, Object(OutputPage))
 * 8) 7 {main}

We checked to make sure the changes in patch 40887 were applied, but this doesn't seem to have made any difference. We seem to have broken something but have no idea what it could be (all our other extensions seem to be working fine). Thanks! --VIngogly 13:35, 12 November 2008 (UTC)