If the only way to register is Google, it should be impossible to create more than one account per Google account.

Why is registration disabled?

To provide some additional context, we originally allowed users to register their own accounts, but we eventually disabled this because we ended up with around 30 duplicate accounts (users with more than one account). I think that this happened because users had listed an alias address in their Phabricator settings, but Google was using a canonical email address to authenticate, which didn't map to any existing user accounts (we have a lot of users that have aliases set up. For example, abraham@mycompany.com would be an alias for the canonical alincoln@mycompany.com address).

Why are users logging into sensitive accounts on shared computers? This action seems inherently unsafe to me.

Specific attack scenario: Phabricator is used to host proprietary code. Someone logs into Phabricator on a shared computer and forgets to log out. That shared computer is now forever logged into his account, allowing anyone using it to access said proprietary code. If the cookie would expire or at least be session-only, the risk would be significantly lower.

Thanks for the info!

It's years away if that, and we wouldn't remove an event handler for registration without significant architecture to move it to.

We always do give warnings, yes. I would recommend subscribing to the weekly Changelog.

In T10700#196511, @chad wrote:

It's a solution you can have in production today, at no cost. Evan noted above we have no immediate plans to remove/replace.

It's a solution you can have in production today, at no cost. Evan noted above we have no immediate plans to remove/replace.

@chad is this really a solution? The events documentation clearly states

@jcarrillo7 see T10700#167773 for solution.

actually, maybe can be done with an EventHandler, I'm reading the code here:

PhabricatorRegistrationProfile is what you want, you can lock email, username, and real name.

In T11716#196494, @chad wrote:

I think you can lock this yourself now by using your own AuthAdapter.

In T11716#196493, @chad wrote:

some users decided to use a different username on phabricator

How did they change their username?

I think you can lock this yourself now by using your own AuthAdapter.

some users decided to use a different username on phabricator

@chad I updated the description. I hope this is more of a root problem.

This doesn't really describe a root problem, see Describing Root Problems. This information is required, so that we may group multiple requests with similar or related problems.

We also say "Only supports JIRA 6" but that means "JIRA 6 or newer", since JIRA 7 works fine.

Basically, if you want to see this implemented, please describe an attack scenario you're concerned about in detail.

This is technically easy for us to implement, I'd just like a real security justification for it. From the first link, the justification seems to be:

See https://github.com/tinfoil/devise-two-factor/issues/30 and https://github.com/mdp/rotp/issues/44 for some discussion about this issue (also discussed a bit on oss-security mailing list as http://www.openwall.com/lists/oss-security/2015/06/20/4).

GHC would also find support for importing keys from Github useful; we are currently working on rolling out a Diffusion-hosted staging area for use with Harbormaster but the need for contributors to submit their key to yet another Phab feels like unnecessary friction.

Ah yes I forgot about the fun of internationalization. Btw those fragments are correct 👍🏻 (I speak Spanish).

Strings with sentence fragments like that can be difficult to translate in the normal human language sense, see:

The translation.override settings seems to be the easiest path forward. I definitely don't want to be modifying the source if I can help it.

This is probably something we'll need in the very long run for T6703 (if we legitimately let you connect to two different LDAP servers, it would be silly to have two "Login with LDAP" dialogs) but, yeah, using translation.override or just editing PhabricatorLDAPAuthProvider might be the shortest path today.

Can you just override the translation? /config/edit/translation.override/

Essentially I would like to customize the "Login or register with LDAP" here to be "Login or register with OpenDirectory"

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.

Closing as invalid since we have no idea what this request is even for. IMAP is a mail protocol, and I'm not sure what you're asking us to do with it.

See Contributing Feature Requests and Describing Root Problems for what information we require in a feature request.

@epriestley Missed a spot: D16325

D16323 uses <input type="text" pattern="\d*" />, which appears to have the best behavior.

On iOS 9.2 in the simulator, <input type="number" /> gives you this keyboard:

Oh, there's a "Toggle Software Keyboard" option that I somehow disabled.

On iPhone Simulator, the behavior of <input type="number" /> appears to be "draw the keyboard for 1 frame and then immediately hide it".

Looks like an iPhone with Gboard keyboard.

Offhand, do you know if <input type="number" /> has the desired behavior on your device?

We haven't gotten to this in two years and haven't really seen other interest. We already support ~8 providers.

The upstream part of this is working in production, and this is now accounted for.

A substantial number of users have linked Google accounts in production and we haven't heard about any issues, so I think that aspect of things is in good shape.

I'm just going to merge this into T5953. The LDAP importer is a contributed patch from yesteryear which we wouldn't bring upstream today, and unlikely to see improvements outside of a more formal upstream effort in T5953.

also affected by this, same report/errormessage.

I believe this is resolved and accounted for, let us know if anyone runs into issues.

Pulled and working! Thanks a lot!

This should be fixed at HEAD of master. Let us know if you're still seeing issues after updating.

Thanks for the report! This should be fixed once D16128 is reviewed, likely later today.

I enabled Google for central auth since I think everything we need for it to work already works fine in the cluster, although it's possible some of the invite flow stuff is a little shaky.

Here's the new AuthProvider code for OAuth2 autologin after D16060:

I'm going to support third-party (as here) and OAuth2 (easy) but we have no use cases for other stuff right now (mostly OAuth1 on Twitter/Jira/Bitbucket, I think).