Topic on Project:Support desk

If you add your username to reserved username, you will not be able to log in or change your password.

I'm setting up a Mediawiki installation and somehow got into a state where my password is not accepted. Since I hadn't yet gotten email configured, I tried to reset my password using the instructions at Manual:ChangePassword.php, but encountered this error:

PasswordError from line 62 of /var/www/mywiki/public_html/maintenance/changePassword.php: * The supplied credentials cannot be changed, as nothing would use them.
* The authentication data change was not handled. Maybe no provider was configured?

Backtrace:
#0 /var/www/mywiki/public_html/maintenance/doMaintenance.php(111): ChangePassword->execute()
#1 /var/www/mywiki/public_html/maintenance/changePassword.php(73): require_once(string)
#2 {main}

Does anyone know how to go about diagnosing this, or what the cause might be? Any advice is greatly appreciated since at the moment I'm unable to administer my wiki. Thanks very much!

MediaWiki=1.29.1, PHP=7.0.22, MySQL=5.7.20.

I am tracking the error.

Due to my lack of ability, I can only give you a suggestion. Try download a new tarball that match your current version from this site, then extract the includes/auth/ directory to overwrite your existing directory of the same name.

I just downloaded a fresh copy of MediaWiki 1.30.0 (the version my installation is now on), and replaced the contents of my includes/auth/ directory with the contents of that directory in the download. Unfortunately the error still persists; this is now the response:

[a4df1cc376641f0cce5b784c] [no req]   PasswordError from line 62 of /var/www/mywiki/public_html/mediawiki-1.30.0/maintenance/changePassword.php: * The supplied credentials cannot be changed, as nothing would use them.
* The authentication data change was not handled. Maybe no provider was configured?

Backtrace:
#0 /var/www/mywiki/public_html/mediawiki-1.30.0/maintenance/doMaintenance.php(92): ChangePassword->execute()
#1 /var/www/mywiki/public_html/mediawiki-1.30.0/maintenance/changePassword.php(73): require_once(string)
#2 {main}

I need more debug information. Please edit mediawiki/includes/auth/AuthManager.php, add var_dump($status); behind $any = $any || $status->value !== 'ignored'; on line 860. Then rerun changePassword.php and observe its behavior, and post error response here.

Note: Do not to modify the file in the production environment. Because it will output debugging information to your web page.

Sure thing; here is the full dump of the response:

The command I run is php changePassword.php --user=UserName --password=NewPassword.

Ok. Then, in the same place, modify as such:

public function allowsAuthenticationDataChange( AuthenticationRequest $req, $checkData = true ) {
        $any = false;
        $providers = $this->getPrimaryAuthenticationProviders() +
            $this->getSecondaryAuthenticationProviders();
        foreach ( $providers as $provider ) {
            $status = $provider->providerAllowsAuthenticationDataChange( $req, $checkData );
            if ( !$status->isGood() ) {
                return Status::wrap( $status );
            }
            $any = $any || $status->value !== 'ignored';var_dump($any);
        }echo "test\n"
        if ( !$any ) {
            $status = Status::newGood( 'ignored' );
            $status->warning( 'authmanager-change-not-supported' );
            return $status;
        }
        return Status::newGood();
}

Rerun changePassword.php.

The result is as follows:

bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
test
bool(false)
bool(true)
bool(true)
bool(true)
bool(true)
test
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
test

I think your LocalPasswordPrimaryAuthenticationProvider have a problem. Most likely is database query problem. Can you access your database directly via command line interface or other connectors?

That's interesting. Yes, I can easily access the database via phpMyAdmin.

Try select action SELECT user_id FROM user WHERE user_name='<UserName>' via phpMyAdmin. (<UserName> is you want to change username) Can you select out a number?

Now I think it is unlikely that the database problem. Maybe other in LocalPasswordPrimaryAuthenticationProvider.

For the user whose password I'm trying to reset, the user_id is 1.

Looks like not a database problem. Edit mediawiki/includes/auth/LocalPasswordPrimaryAuthenticationProvider.php, add var_dump($row); behind ); on line 222., then rerun changePassword.php.

OK, I've made that addition to LocalPasswordPrimaryAuthenticationProvider.php; below is the result from running changePassword. (Nothing extra seems to appear from the dump.)

[2f16bf0d63423d2400ce46db] [no req]   PasswordError from line 62 of /var/www/mywiki/public_html/mediawiki-1.30.0/maintenance/changePassword.php: * The supplied credentials cannot be changed, as nothing would use them.
* The authentication data change was not handled. Maybe no provider was configured?

Backtrace:
#0 /var/www/mywiki/public_html/mediawiki-1.30.0/maintenance/doMaintenance.php(92): ChangePassword->execute()
#1 /var/www/mywiki/public_html/mediawiki-1.30.0/maintenance/changePassword.php(73): require_once(string)
#2 {main}

Oh, now. Edit mediawiki/includes/auth/LocalPasswordPrimaryAuthenticationProvider.php, add var_dump($username);behind $username = User::getCanonicalName( $req->username, 'usable' ); on line 215., then rerun changePassword.php.

The response is bool(false).

What username did you input when you run changePassword.php?

Huwmanbeing is the username I'm inputting.

Please use the following code to edit your line 1092-1141 in includes/user/User.php.

The response:

test1
test2
test1
test2
bool(false)

Maybe, I find the problem point. Are you set $wgReservedUsernames in LocalSettings.php? Or do you installed an extension that blocks users from logging in or registering?

I don't have any $wgReservedUsernames defined in LocalSettings.

I do have new account creation turned off for unregistered users ($wgGroupPermissions['*']['createaccount'] = false;). I tried re-enabling account creation and re-running changePassword but the result is the same.

I have several extensions installed, but none specifically for blocking logins or registrations. Other than the three automatically-installed "spam prevention" extensions (ConfirmEdit, SpamBlacklist, and TitleBlacklist), I have two others: Abuse Filter and AntiSpoof. I've tried disabling them both and re-running changePassword but that also didn't seem to change anything.

Very strange. Add var_dump($reservedUsernames); to line 912 in includes/user/User.php.

Yes, it's very odd — I really appreciate all your help with trying to track it down. Here's the result from var_dump($reservedUsernames):

array(12) {
  [0]=>
  string(17) "MediaWiki default"
  [1]=>
  string(17) "Conversion script"
  [2]=>
  string(18) "Maintenance script"
  [3]=>
  string(40) "Template namespace initialisation script"
  [4]=>
  string(14) "ScriptImporter"
  [5]=>
  string(12) "Unknown user"
  [6]=>
  string(25) "msg:double-redirect-fixer"
  [7]=>
  string(22) "msg:usermessage-editor"
  [8]=>
  string(16) "msg:proxyblocker"
  [9]=>
  string(20) "msg:spambot_username"
  [10]=>
  string(23) "msg:autochange-username"
  [11]=>
  string(25) "msg:newusermessage-editor"
}

Add echo "test\n"; to line 921 in mediawiki/includes/user/User.php behind behind }.

This should be the last debugging if you get test. Since, this is not logical.

I added that echo to the end of line 921; the result appears unchanged. Here's the full response:

Do you suspect it's something amiss with reserved usernames?

Yes, there should be have a problem. This should a last test: add var_dump($reserved);var_dump($name); to line 919 in the same file before return false;.

Here's the result:

That is it. You situation that due $reserved == $name so User::isUsableName() return false and cause you can't change the password. But I do not know why your name will be in $reservedUsernames array. Please add var_dump($reservedUsernames); to line 919 in the same file before return false;. Oh, previous code for debugging can be remove.

How interesting. When at first I couldn't log in I wondered how my password could have gotten changed without my knowledge; perhaps the answer is that it never did, and instead it's this strange connection to $reservedUsername that's blocking my login.

With just var_dump($reservedUsernames); added to line 919, this is the result:

array(12) {
  [0]=>
  string(17) "MediaWiki default"
  [1]=>
  string(17) "Conversion script"
  [2]=>
  string(18) "Maintenance script"
  [3]=>
  string(40) "Template namespace initialisation script"
  [4]=>
  string(14) "ScriptImporter"
  [5]=>
  string(12) "Unknown user"
  [6]=>
  string(25) "msg:double-redirect-fixer"
  [7]=>
  string(22) "msg:usermessage-editor"
  [8]=>
  string(16) "msg:proxyblocker"
  [9]=>
  string(20) "msg:spambot_username"
  [10]=>
  string(23) "msg:autochange-username"
  [11]=>
  string(25) "msg:newusermessage-editor"
}

Although impossible, but check these pages in your wiki:

• mediawiki:double-redirect-fixer
• mediawiki:usermessage-editor
• mediawiki:proxyblocker
• mediawiki:spambot_username
• mediawiki:autochange-username
• mediawiki:newusermessage-editor

does it include your name. And use index.php?search=Huwmanbeing&title=Special:Search&profile=advanced&fulltext=1&ns8=1 URL to search your wiki, if you find your name included in these pages...

One of those messages has been customized to Huwmanbeing presumably?

Set $wgReservedUsernames = []; in LocalSettings.php should can fix it.

Success! Thank you so much for your diligence in diagnosing this problem — I greatly appreciate it.

Here's the coda to the story. After setting $wgReservedUsernames = [] I re-ran changePassword.php and saw this:

array(1) {
  [0]=>
  string(25) "msg:newusermessage-editor"
}

NewUserMessage is an extension that automatically posts a message to the talk pages of newly-created users. After disabling that extension, I was able to log in without issue — and I verified that changePassword worked fine too. The source of the problem was apparently the MediaWiki:Newusermessage-editor setting, which was set to "Huwmanbeing". I've now set up a separate account just for that extension to use for posting welcome messages.

Thanks again!

Yes, I see Set the username of the user that makes the edit on user talk pages. If this user does not exist, "MediaWiki default" will show up as editing user. The user set here is marked as reserved and won't be able to login! in Extension:NewUserMessage#In-wiki configuration. I'm not sure if I want to add this case to Manual:changePassword.php as troubleshooting note.

Just pinging for a response. Any thoughts? Huwmanbeing (talk) 20:52, 18 January 2018 (UTC)

Do you have an authentication provider enabled? Do you use any authentication extensions? OAuth?

No, I haven't installed anything authentication-related. I just upgraded from 1.29.1 to 1.30.0 to see if that might address the problem, but unfortunately no luck. I'm baffled about how to diagnose and solve this. Huwmanbeing (talk) 13:52, 21 January 2018 (UTC)

1: Reset your localsettings.php to as basic as you can 2: Make sure you ran maintainance/update.php 3: Follow Manual:How_to_debug

I've run update.php and temporarily pared out as much as I can from LocalSettings. I also set up a $wgDebugLogFile to get more detail, and attempted to make the change via both changePassword.php and the Special:PasswordReset page, but it doesn't seem to shed much light. There's one relevant line which notes...

[authentication] User1 attempted password reset of User2 but failed

...but otherwise gives no indication of exactly why it failed, and concludes with "the request ended normally". Huwmanbeing (talk) 15:01, 22 January 2018 (UTC)

Is it possible that email needs to be set up and working in order to use changePassword? (Since I'm having some problems with SMTP, just wondered if that might affect this.) Might be no connection, but I'm grasping at straws...

Email isn't necessary to run changePassword.php. You can try Manual:CreateAndPromote.php to change the password, but it looks like you have some sort of alternative for user authentication set up.

Good thought; I just tried CreateAndPromote with --force to try resetting a password for the account, but unfortunately the result is the same:

The authentication data change was not handled. Maybe no provider was configured?
Backtrace:
#0 ...mediawiki-1.30.0/maintenance/doMaintenance.php(92): CreateAndPromote->execute()
#1 ...mediawiki-1.30.0/maintenance/createAndPromote.php(154): require_once(string)
#2 {main}

I don't recall establishing anything out of the ordinary for user authentication. (I normally have new account creation turned off, but the error also occurs when it's on.) What does it mean by "no provider configured"? Do you know of any way to determine what's happening?

Sounds like you have disabled local password authentication. Check $wgAuthManagerConfig / $wgAuthManagerAutoConfig. (The easiest way is probably to run maintenance/shell.php and then just type in the names of those variables.)