It's a Google-specific routine in the app (and only works when you set up your Google account with it), not a part of the TOTP standard. Servers implement scratch codes in their own ways.

IIRC the google authenticator app itself gave me one-time use codes when I first set it up. What client side app are you using?

Any progress on this?

Hi @epriestley that ticket is exactly what I'm after. Much thanks.

REMOTE_USER can come from a lot more sources than just HTTP Basic Auth. E.g. I would use it for GSSAPI authentication. Could you maybe change the bug title?

• In PhabricatorAuthApplication->buildMainMenuItems(), add ?next=<the current path> to the "Log In" item.

The utf8 stuff hasn't been coming up much; the token-based stuff is just blocked on docs and also hasn't come up much; I touched the protocol enough that I'm pretty confident we can move forward without backward compatibility breaks.

Seems reasonable to support this.

Facing the similar problem, but with two Google accounts.

Our security team is driving the request, we have some strict compliance requirements around session expirations for internal services, so I'll be monkey patching this so long as it's unresolved.

@beeerd, do you have a specific problem / use case driving your interest?

Would love to have this feature!

FWIW today we got a second report.

At least for now, this no longer blocks Phacility or T2783.

T2783 is at least partially blocked on this, since I need to make intra-cluster calls as the viewing user and don't want to do handshakes. I also don't really want to ship session keys across in the raw, although that wouldn't be the end of the world. I'll probably push this about halfway forward and then drop it again once T2783 is unblocked.

Aaaaah, okay. I'm guessing that will probably repro across other providers. Thanks!

Hey, im the one who reported/suffers from this.

I don't see any option to add a second MediaWiki account... In Wikimedia Phabricator I see MediaWiki and LDAP linked to one account each, then "Your account is linked with all available providers." under "Add External Account".

Well, maybe I'm wrong. I can't reproduce this with other account types. For example, I have no option to attach a second Facebook account:

In particular, this is very unlikely to be particular to Mediawiki, and should reproduce with other providers (like GitHub). (If it doesn't, there's just an issue we need to fix with the MW adapter.)

Expected behavior is that this is prevented until T2549, which will eventually make this work properly.

@qgil That's T2549, but the exception is not expected behavior. If you want to file that, we can fix it -- it's supposed to prevent attaching a second account until we support multiple accounts properly.

For what is worth, we have the case of users with two Wikimedia accounts, and some of them do try to attach them to the same Phabricator account. The result is 'Attaching' two mediawiki accounts results in AphrontCountQueryException.

I concur, the interest is limited, and it clearly belongs to the category of narrow use cases.

Please see https://secure.phabricator.com/book/phabcontrib/article/contributing_code/. The main concern here is we're not likely to take this into the upstream (as in, support indefinitely) without a lot of interest. I've only seen 1-2 requests for this over the past few years.

@limanoit has added some days later a love token to Q36.

Unless you specifically instructed the users who did click the links to immediately go to Settings > External Accounts and link their LDAP accounts, they're not really in better shape: they'll get locked out of their accounts as soon as they log out, too. Their LDAP credentials are not tied to their accounts. We never tie credentials together based on email addresses or usernames, because these aren't trustworthy across authentication sources.

Unless you specifically instructed the users who did click the links to immediately go to Settings > External Accounts and link their LDAP accounts, they're not really in better shape: they'll get locked out of their accounts as soon as they log out, too. Their LDAP credentials are not tied to their accounts. We never tie credentials together based on email addresses or usernames, because these aren't trustworthy across authentication sources.

This seems to have gotten a little bit too deep, but I might be misunderstanding something.

In the long run, I think the ideal workflow here is to make import/create more of a function of providers -- so you enable LDAP and get "Import from LDAP" (users would recover by logging in with their LDAP credentials), enable Google and get "Import from Google" (users would recover by logging in with their Google credentials), enable Facebook/GitHub/Whatever and get "Import from list of accounts in a CSV file" or something (users would recover by logging in with their service credentials), and enable username/password and get "Create New Account" (users would recover via password reset -- I think they already get cued about this, maybe?). We could let you "Create New Account" anyway, maybe, but since you can do that via the CLI if you really intend to do advanced stuff it might be more straightforward to simply remove it from the web UI.

(That title might be a little clearer?)

On SAAS, I believe the current plan is zero LDAP support, so it's moot.

Possibly we should have some kind of warning on People > Create New User if password auth is not enabled, since it's a confusing/advanced feature in that case (users must follow the links promptly, must link an external account, can not recover credentials, and don't get UI prompting).

I don't have everything set up locally, but two general pieces of information:

I'm actually not familiar with the LDAP stuff as I don't have a working LDAP server. Adding in my cohorts though.

We don't have username/password authentication enabled - just LDAP. Is that a bad idea?

Er, not a 404, a permissions dialog.

Theory here is that the image isn't being created with the right permissions when we pull it from the authentication service. Then the user tries to load it, hits a 404 in the background, and gets a cookie set.

This has Support Impact

Note it is possble to get a 400 error if you do not have the Username / Password auth enabled. If its a 400, see http://<domain/auth/ for your settings. If you don't have the Username / Password auth type enabled, turning it on should fix this workflow. That said, please let us know what the settings you do have here are as I don't think you should have fallen into this hole with any combination of settings.

In T6479#82521, @anton.vladimirov wrote:

Looks like we’re getting a 404 error for http://<domain>/login/email/

As we approach Wikimedia 's Bugzilla to Phabricator migration (planned to start on Nov 21), more users are registering to our instance and we hear more about "suitcase icon" cases. Today we got a user bothered enough to file a bug: https://phabricator.wikimedia.org/T1138

Context from IRC:

Looks like we’re getting a 404 error for http://<domain>/login/email/

Let us know what the URI is on the 404 page.

Hmm, nope - I was definitely seeing a 404 after clicking the button to send another email.
I'll try again tomorrow and see if I can get any more specific info.

fwiw I do not repro. my steps were