Page MenuHomePhabricator

Support linking multiple external accounts from the same provider with one Phabricator account
Closed, WontfixPublic

Description

When I originally set up my http://secure.phabricator.com account, I connected with my Locu Google Apps account. This was a mistake; I should have used my personal Gmail account.

Just now I accidentally logged in on my home computer with my personal account, creating "mierle" (instead of my preferred account name of "keir"), not realizing until after I had created the account that it was the wrong one.

I have two questions:

  1. Is it possible to delete the "mierle" account (there are no actions associated with it)
  2. Is it possible to add another connected Google account to "keir"?

Event Timeline

  • I deleted the @mierle account.
  • It's currently not possible to link a Phabricator account to more than one external account of a given type (where "type" is one of "Facebook", "Google", "GitHub", etc.). In hindsight this was an architectural mistake, but I didn't think about it at the time and left us with a mess to clean up. It will be resolved by {T1536}, which is a sort of umbrella task for remedying various missteps on the auth pathway. We've made some progress on that, but it will be at least a little while before it lands.
epriestley triaged this task as Normal priority.Feb 15 2013, 2:59 PM

This applies to the Persona provider (T3958) as well.

epriestley renamed this task from Support linking multiple Google IDs with one account to Support linking multiple external accounts from the same provider with one Phabricator account.Oct 14 2013, 11:04 PM

Now i linked two Google accounts with my phabricator account, is there any way to remove one of them?

pasted_file (371×854 px, 70 KB)

Refresh or delete any of them will lead AphrontCountQueryException:

pasted_file (103×425 px, 13 KB)

Can i directly delete the related row in phabricator_user.user_externalaccount table from my database?


Update: I deleted it by editing database directly :P

chad changed the visibility from "All Users" to "Public (No Login Required)".Jul 23 2015, 4:41 AM
eadler added a project: Restricted Project.Apr 7 2016, 6:11 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
cburroughs moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 20 2016, 3:56 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 4 2016, 9:19 PM
  • I deleted the @mierle account.
  • It's currently not possible to link a Phabricator account to more than one external account of a given type (where "type" is one of "Facebook", "Google", "GitHub", etc.). In hindsight this was an architectural mistake, but I didn't think about it at the time and left us with a mess to clean up. It will be resolved by {T1536}, which is a sort of umbrella task for remedying various missteps on the auth pathway. We've made some progress on that, but it will be at least a little while before it lands.
epriestley closed this task as Wontfix.EditedDec 12 2018, 7:53 PM
epriestley claimed this task.

There are two flavors of this:

  1. Linking one Phabricator account with multiple accounts of the same type on a single remote service (e.g., linking to several different GitHub accounts).
  2. Linking one Phabricator account with multiple accounts of the same type on different remote services, one per service (e.g., linking to different LDAP accounts on different LDAP servers).

T6703 covers (2).

Although we probably should permit (1), I think the use cases for it are much weaker. In almost all cases, this arises because you want to link account B and accidentally linked account A instead. In these cases, you can unlink account A and link account B. If you somehow lose your session between unlinking and re-linking, you can use an email link to regain access to your account, or an administrator can bin/auth recover it for you.

I think the use case here is probably already covered, and it sounds like (1) wouldn't really have helped in the case of T10452.

I think the work to make this function probably isn't worthwhile in the absence of a strong use case, and I don't think I've seen one. The use cases in T6703 are sufficiently reasonable and the architecture there is clearly wrong as motivations for (2), but I think (1) is on far shaker ground and don't expect to pursue it until more motivation arises.

I believe that instead of T7667 you meant to write T6703.