Sorry, yeah, I meant T6703.

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

There are two flavors of this:

...and here are foreseeable issues with this mess occurring in the wild:

Broadly, I want to avoid implementing things that don't have good technical justifications.

I've done some more digging as well and it appears that this issue arose in the Go library already: https://github.com/golang/oauth2/issues/111

Is "GitHub-specific OAuth" just normal OAuth with client_id / client_secret as parameters instead of in an "Authorization" header? The GitHub OAuth documentation seems to suggest passing these as parameters, too.

It seems like section 2.3.1 is poorly worded. They talk about a "client password" but the example request only includes client_secret as a POST variable. In the case of the Golang OAuth2 module (which Concourse uses), it sets the basic auth username to the client ID and the password to the client secret (https://github.com/golang/oauth2/blob/master/internal/token.go#L164).

I don't think we have a "client password" in this case -- I believe that refers to a mode that no one uses for anything (well, maybe a mode that Concourse uses, I guess), where the flow is actually handling normal user passwords?

In T2549#25878, @epriestley wrote:

• 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.

Thanks for the quick fix.
I realise now I was always trying to change the access policies....

I can only reproduce this if (3) is changing "Visible To", exactly: i.e., same file policy scrambling issue as T10778. Should have the same fix.

Ref T10778

I am going to merge this into T7303, which is a slightly narrower task describing OAuth access to Conduit.

That stuff will deploy on ~Saturday, new UX is roughly this:

I figure I'll toss this on my queue, though I want to do other things first.

This is actually a blocker (for launch, not blocking anything in the short term) because the view policy is always "All Users", and you only need View to see the secret. We should modernize the application:

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

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

See @chad's link for discussion.

Oauth Server is a Prototype Application, https://secure.phabricator.com/book/phabricator/article/prototypes/