Page MenuHomePhabricator

PhabricatorAuthProviderOAuthGoogle and PhabricatorAuthProviderPassword both show Provider Implementation Missing!
Closed, InvalidPublic


Both Google auth provider and Password auth provider show Provider Implementation Missing! after an upgrade. I was able to login using bin/auth recover but users are locked out. I am unable to add new provider, fails for duplicate provider auth key.

What should I do?

Event Timeline

vnykmshr assigned this task to epriestley.
vnykmshr raised the priority of this task from to Needs Triage.
vnykmshr updated the task description. (Show Details)
vnykmshr added a project: Auth.
vnykmshr added a subscriber: vnykmshr.

I have updated auth_providerconfig in phabricator_auth.auth_providerconfig table to something else and added new Google provider from web interface. Not sure if this is the correct way but it worked.

What is your upgrade process, specifically? Did you restart apache/php-fpm?

I ran upgrade on very old install of phabricator, hadn't been updated for as long as 9 months. I ran into few issues during upgrade, but eventually managed to complete storage upgrade.

I had no auth provider working left, couldn't add them back for duplicate provider key. I then updated the existing entry to Google_ and added new provider.

Right now I'm facing issues with Password auth provider: Malformed password hash, expected "name:hash"

This issue has been reported previously and supposedly fixed. But I need to find a fix for this, as it's not working for me.

We need the specific errors you ran into, the commands you ran next, everything. We have no means of reproducing the issue as you're currently describing it. Without knowing the specifics, we can't provide you with help or see if there is even something in the upstream to fix.

T4463 is the only other related task I can find mentioning your error, is that the task you are referring to?

Yes I found T4463 while I was searching for the issue. Here's log of issues I faced during upgrade;

  1. Unable to apply patch 'phabricator:20150116.maniphestapplicationemails.php': Table 'phabricator_spaces.spaces_namespace' doesn't exist. (T8743). I commented out 20150116.maniphestapplicationemails.php to skip this patch, this commit fixed actually fixed the issue.
  2. I let all other patches as is, which took a long long time but concluded with storage adjustments issues (surplus schemata). I will take this up next and resolve.
  3. We use Google and Password auth providers, both stopped working after the upgrade, and I had to recover my account using bin/auth. I have added the providers again, after renaming the auth_providerconfig in phabricator_auth.auth_providerconfig from mysql.

This is all I have done. Need to fix this issue: Malformed password hash, expected "name:hash" as it keeps coming even after trying to reset a password.

Is there a patch I may have missed (unlikely) that migrates old passwords to name:hash format?

The expectation is that 20140722.renameauth.php renamed provider classes, and 20140218.passwords.2.prefix.sql reformatted the passwords.

Do these show as "applied" in bin/storage status?

You can try re-applying them explicitly with:

phabricator/ $ ./bin/storage upgrade --apply phabricator:20140218.passwords.2.prefix.sql
phabricator/ $ ./bin/storage upgrade --apply phabricator:20140722.renameauth.php

But there's no reason these two patches should have randomly gone missing, so the fact that they didn't apply properly suggests there may be some deeper issue.

Also note that 20140218.passwords.2.prefix.sql is not idempotent, so re-running it if it already ran could break things.

bin/storage status shows both patches as applied.

phabricator:20140722.renameauth.php                       Applied php  /var/www/html/taskmanager/phabricator/resources/sql/autopatches/20140722.renameauth.php
phabricator:20140218.passwords.2.prefix.sql               Applied sql  /var/www/html/taskmanager/phabricator/resources/sql/autopatches/20140218.passwords.2.prefix.sql

But I also noticed out 500+ entries in phabricator_auth.user, passwordHash field on 89 entries were not prefixed with md5:. I have manually prefixed md5: to these entries, hope its alright.

We can't reproduce any of this and no other users have reported similar issues. Some of the issues described here are likely access/permissions issues, which should be communicated more clearly after D15079 / D15080.