Extension talk:Password Reset/Archive 01

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. →Tim Laqua^{Talk | contribs}_{@18:09, 19 November 2007 (UTC)}

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.
→Tim Laqua^{Talk | contribs}_{@12:11, 20 November 2007 (UTC)}

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? →Tim Laqua^{Talk | contribs}_{@17:03, 20 November 2007 (UTC)}

Yes :-) If you see really everything translated, but only this extension not... SPQRobin 18:39, 20 November 2007 (UTC)

Done in r27718.

Feature request: disable user

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

• 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.
Tim Laqua ^talk 08:22, 13 December 2007 (UTC)

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:
PasswordReset_Disabledusers.php and PasswordReset_body.php are NOT compatible anymore. PasswordReset_body.php sets a password to null in case of disabling an account, PasswordReset_Disabledusers.php 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 PasswordReset_body.php.

'Tis a community software development issue ;-) This extension was refactored a while back by others in the community (that's where the NULL password came from) and that's also why the disabled users list doesn't work anymore. I don't have a testing environment for MediaWiki anymore (I'm with a 100% .NET shop now) - but I can try to find a time to take a look in the next few weeks if it still hasn't been looked at by someone else. Tim Laqua ^talk 11:34, 29 December 2008 (UTC)

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)

But honestly, i've never seen $wgPasswordSalt set to false. 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?
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)

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 {{clickpic}} work...)

$wgServer (since I'm on a subdomain — 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

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
Tim Laqua ^talk 02:10, 17 April 2008 (UTC)

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:

• Special:PasswordReset
• Special:Disabledusers

--199.243.65.6 14:13, 2 June 2008 (UTC)

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 rev: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.

PasswordReset revision 40887 patch

diff -x .svn -Naurb PasswordReset-r40887/PasswordReset_body.php PasswordReset/PasswordReset_body.php --- PasswordReset-r40887/PasswordReset_body.php 2008-09-15 19:37:41.000000000 -0300 +++ PasswordReset/PasswordReset_body.php 2008-09-15 19:46:28.000000000 -0300 @@ -23,7 +23,7 @@ $this->setHeaders(); - if ( !$wgUser->isAllowed( 'passwordreset' ) || !$wgUser->isAllowed( 'passwordresetself' ) ) { + if ( !$wgUser->isAllowed( 'passwordreset' ) ) { $wgOut->permissionRequired( 'passwordreset' ); return; } @@ -180,7 +180,7 @@ return true; } else { $u->load(); - if ( $u->mPassword == 'DISABLED' ) { + if ( $u->mPassword == '' ) { $user->mBlockedby = 1; $user->mBlockreason = wfMsg( 'passwordreset-accountdisabled' ); } @@ -189,7 +189,7 @@ } } } elseif ( $user->isLoggedIn() ) { - if ( $user->mPassword == 'DISABLED' ) { + if ( $user->mPassword == '' ) { global $wgOut; //mean, I know. $user->logout(); diff -x .svn -Naurb PasswordReset-r40887/PasswordReset_Disabledusers.php PasswordReset/PasswordReset_Disabledusers.php --- PasswordReset-r40887/PasswordReset_Disabledusers.php 2008-09-15 19:37:41.000000000 -0300 +++ PasswordReset/PasswordReset_Disabledusers.php 2008-09-15 19:05:08.000000000 -0300 @@ -61,7 +61,7 @@ user_id, user_name as value FROM $user - WHERE user_password='DISABLED'"; + WHERE user_password=''"; } function sortDescending() {

--CrazyTerabyte 22:10, 15 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.  :-(
Tim Laqua ^talk 00:07, 16 September 2008 (UTC)

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. [1]

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:
#0 /usr/local/apache2/htdocs/wiki/includes/SpecialPage.php(572): Language->getSpecialPageAliases()
#1 /usr/local/apache2/htdocs/wiki/includes/SpecialPage.php(586): SpecialPage::getLocalNameFor('Recentchanges', false)
#2 /usr/local/apache2/htdocs/wiki/includes/OutputPage.php(1451): SpecialPage::getTitleFor('Recentchanges')
#3 /usr/local/apache2/htdocs/wiki/includes/SkinTemplate.php(243): OutputPage->getHeadLinks()
#4 /usr/local/apache2/htdocs/wiki/includes/OutputPage.php(821): SkinTemplate->outputPage(Object(OutputPage))
#5 /usr/local/apache2/htdocs/wiki/includes/Wiki.php(337): OutputPage->output()
#6 /usr/local/apache2/htdocs/wiki/index.php(94): MediaWiki->finalCleanup(Array, Object(OutputPage))
#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)

2009

This is useless unless users are stopped from requesting passwords by email

Just got the latest from SVN (47358), with MediaWiki 1.12.0, and users who are "disabled" can request temp passwords by email. Is there any update on this since the observation some months ago? --pfctdayelise 13:55, 17 February 2009 (UTC)

Extension:EditUser can be used to remove a user's email address, but you could also use that to manually scramble people's passwords, making this not so necessary. I would prefer that this extension removed a user's email address itself. --pfctdayelise 14:15, 17 February 2009 (UTC)

See bug below - may explain the problem.

Bug about PasswordReset

Hi! I've opened a bug about this extension... Bug is the #19042... Bye!--Marco 27 08:37, 14 June 2009 (UTC)

I have closed the bug, I can't reproduce this on 1.18alpha (r84930) wiki.  « Saper // talk »  23:18, 28 March 2011 (UTC)

Bug - may explain other earlier issues

I use PasswordReset on a 'private wiki', and occasionally use the "Disable User" function. Unfortunately, this currently involves a manual database edit.

In PasswordReset_body.php, there are the following lines:

if ( $disableuser ) {

$user->setPassword( null );
$message = wfMsg( 'passwordreset-disablesuccess', $userID );

The user password hash is invalid, and they can no longer log in. However, when other parts of the extension refer to the database to find out whether a user is disabled or not, it looks for "$u->mPassword == 'DISABLED'", but it was originally set to 'null'. This also means that users can continue to reset their passwords even when disabled.

I tried using the 'setPassword' function to add DISABLED instead, but it seems that function does the hashing job itself, and so the database ends up with a hashed form of the word "DISABLED".

I don't know exactly how to insert code to do a direct database write without messing dependent aspects up in MediaWiki, but I believe that is the solution - to directly write the text "DISABLED" to the user_password field in the user table.

Bug 23 Jan 2011 about Password Reset

I created the PasswordReset directory and also created the 5 files. I set the permissions as wxr-xr--x (similar to other working extensions). However, when I now click on Special Pages the screen does not render. If I go directly to the page below it works.

       http://10.3.200.51/mediawiki/index.php/Special:PasswordReset  

But my Special Pages has stopped working.

This is the error (when I enabled error logging in LocalSettings.php)

Fatal error: Can not call constructor in /opt/bitnami/apps/mediawiki/htdocs/extensions/PasswordReset/PasswordReset_Disabledusers.php on line 16

Any thoughts

You need to use the version of the extension that corresponds to your version of MediaWiki. —Emufarmers^(T|C) 17:12, 23 January 2011 (UTC)

Thanks for the suggestion. I am running a Bitnami VMware of MW V1.16 (which is embedded in the filename of the VMware image). I downloaded the Extension file "PasswordReset-MW1.16-r62678.tar" (this indicates to me it is V1.16). That doesn't appear to be the problem. Lorenzo - 26 JAN 2011.

On my 1.16 setup, I get that error with the trunk version of the extension and not with the 1.16 version. Are you sure you overwrote the existing extension files with the 1.16 ones? —Emufarmers^(T|C) 03:05, 26 January 2011 (UTC)

Touche. You are correct. I now recall that I cut and pasted the text of the files from the links. Doh! When I copied the files across from the tar it worked a treat. Thanks muchly for helping out. "A most embarassed" Lorenzo 28 JAN 2011. Issue Solved.

Can't get it work

I've added the files under a new extensions/PasswordReset folder.

Also, added the 2 lines on LocalSettings.php, and even restarted my wiki.

Then going to /index.php/Special:PasswordReset takes me to a regular page that lets me only change my password, but not reset mine or other users' passwords.

I've checked and my user is associated to the sysop group, and on group permissions page I see that sysop does have the passwordreset permission.

Any ideas? BTW. My wiki is not in English, but in different language.

Koby