Page MenuHomePhabricator

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

Authored by epriestley on Feb 21 2020, 3:54 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Apr 11, 7:40 AM
Unknown Object (File)
Mar 14 2024, 6:06 PM
Unknown Object (File)
Feb 21 2024, 12:24 PM
Unknown Object (File)
Feb 14 2024, 7:57 AM
Unknown Object (File)
Feb 12 2024, 11:14 AM
Unknown Object (File)
Feb 3 2024, 11:43 PM
Unknown Object (File)
Jan 25 2024, 2:12 AM
Unknown Object (File)
Jan 8 2024, 6:33 AM
Subscribers
None

Details

Summary

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

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable