Page MenuHomePhabricator

Update unusual handling of external accounts in "Password" auth provider

Authored by epriestley on Feb 21 2020, 3:54 PM.
Referenced Files
F13239329: D21014.diff
Wed, May 22, 1:58 AM
F13237074: D21014.diff
Tue, May 21, 12:22 PM
F13230960: D21014.diff
Mon, May 20, 11:28 PM
F13225367: D21014.id50059.diff
Sun, May 19, 2:53 PM
F13223913: D21014.id50077.diff
Sun, May 19, 5:17 AM
F13213216: D21014.diff
Fri, May 17, 7:31 AM
F13206193: D21014.id50077.diff
Wed, May 15, 6:00 AM
F13206062: D21014.id50058.diff
Wed, May 15, 4:54 AM



Depends on D21013. Ref T13493. When users log in with most providers, the provider returns an "ExternalAccount" identifier (like an Asana account GUID) and the workflow figures out where to go from there, usually a decision to try to send the user to registration (if the external account isn't linked to anything yet) or login (if it is).

In the case of password providers, the password is really a property of an existing account, so sending the user to registration never makes sense. We can bypass the "external identifier" indirection layer and just say "username -> internal account" instead of "external GUID -> internal mapping -> internal account".

Formalize this so that "AuthProvider" can generate either a "map this external account" value or a "use this internal account" value.

This stops populating "accountID" on "password" "ExternalAccount" objects, but this was only an artifact of convenience. (These records don't really need to exist at all, but there's little harm in going down the same workflow as everything else for consistency.)

Test Plan

Logged in with a username/password. Wiped the external account table and repeated the process.

Diff Detail

rP Phabricator
Lint Passed
Advicesrc/applications/auth/provider/PhabricatorAuthProvider.php:258XHP16TODO Comment
Tests Passed
Build Status
Buildable 23883
Build 32862: Run Core Tests
Build 32861: arc lint + arc unit