I don't think this is worth bringing upstream. It very occasionally saves users one click on an otherwise straightforward workflow, but requires significant complexity and maintenance from the upstream.

If you only have one OAuth provider, you can "Allow Auto Login" for that provider to get this behavior in all cases.

Is the actual problem here that you have multiple providers (say, LDAP and also Google OAuth) and that users are confused about which they should use? If so, why do you have multiple providers?

We generally don't consider a root problem of "Phabricator lacks feature" as a reason to accept a feature request. We still need to know the underlying problem.

@epriestley: Yes, we have multiple authentication providers configured and needed in phabricator, and thus "allow auto login" won't work.

@chad: Underlying problem is that we want to have seamless SSO for users coming from our internal portal. In that use case we want to send users to the "start authentication against specific oauth provider" -URL, which makes phabricator redirect the browser to the specified oauth IDP starting the authentication process automatically, and makes the whole SSO process seamless for the end user. This way we can make sure all the users coming from our portal always use the correct IDP, and won't have problems signing in to phabricator.

About "significant complexity and maintenance": this proposed feature is actually a single URL endpoint on phabricator, and it's common shared code for all of the oauth providers in phabricator, meaning it works with *all* of the existing oauth authentication providers.. and it uses the same oauth code that's used today for the enduser manually initiated oauth logins. So not sure about it being "significant complexity".. your viewpoint obviously might differ :)

Why do you have multiple authentication providers?

@epriestley : we need multiple authentication providers because this is a shared phabricator instance, and thus different groups of users need different IDP.

Why are you sharing an instance between two separate groups with separate identity providers?

@epriestley : because it's easier to manage everything from a single instance of phabricator. Phabricator has native support for multiple authentication providers, so I don't see a problem with this.

In my experience, it is very unusual for organizations to have multiple distinct internal groups with different identity providers. Normally, organizations which value SSO and identity management consolidate identities under a single provider, because that avoids problems like this, greatly simplifies identity management, and doesn't require other pieces of software to support multiple providers.

This is so rare that we don't even support this in the general case (see T6703). For example, it is not currently possible to configure Phabricator to use two different LDAP providers. Although this is a feature we plan to implement eventually, we've seen very little interest in it and the driving use cases are largely not around running multiple providers for an extended duration (instead, they focus on situations like migrating between providers; see also T2549).

Because we are committing to maintaining upstream features indefinitely, it is very important to us that features in the upstream solve general problems experienced by multiple installs, not problems which are experienced by only one install.

It's also important that we're providing good solutions to real technical problems, not workarounds for problems that companies make for themselves. We sometimes receive requests to implement features which only make sense in the context of some other problem, like a third-party not supporting something or an organization having a very unusual technical policy. For example, Facebook once asked us to implement features because they had put their databases and repository servers in datacenters 3,000 miles apart using NFS replication that caused multiple minutes of replication delay (we declined, and suggested they move their servers closer together).

All of this is explained in more detail in Contributing Feature Requests.

If you believe the feature you want isn't very complex and that you're making a very small request of us: great! You can implement it locally yourself and maintain the patch, which shouldn't be much work since you don't believe it represents a significant burden on the upstream.

If the feature you want is large enough that you don't want to develop or maintain it, we need you to work with us to understand the context your organization exists in, why you have this unusual setup and problem, why this feature is a good technical solution to the problem, and why this isn't just a request to work around a questionable or complex organizational policy by shifting the burden of poor planning onto us.

We will never implement features without first developing this deep understanding of the context they exist in and the problems they're solving, because we're committing to maintaining them indefinitely. This is a huge, long-term burden, so we believe it is reasonable to ask you to bear as much of the burden as you can up front by describing the problem you're facing -- not just requesting a feature -- so we can find different solutions and evolve solutions as other problems arise and needs change. This is explained in more detail in Describing Root Problems.

From the information you've provided, here's my guess about what's going on: it sounds like your organization has an unusual authentication setup with two or more separate SSO authorities. I assume this setup exists for historical reasons (perhaps you acquired another company, or were yourselves acquired, and the two organizations' SSO systems haven't been merged) and causes many other problems, but is very hard to fix. Because fixing that root problem is too difficult, you're trying to work around the problem in other software like Phabricator. Specifically, you're running into an issue where users are confused about which authentication option they should use.

If that's the case, we'd like to see this hypothetical problem description instead of the one you filed:

My company acquired another company three years ago, and we have two completely different SSO systems which don't know about each other. We haven't fixed this in the last three years because it's a lot of work and it's hard to prioritize internally since the two systems are owned by competing teams locked in an internal battle over the same budget. About two years ago, we started using Phabricator, and just associated it with both SSO systems. When new users go to log in they often aren't sure if they should login with LDAP (our SSO system) or Google (the acquired company's SSO system) and sometimes click the wrong one and get confused or worse. We'd like to provide direct links to login with a particular provider, so our two different SSO portals can link to two different login flows...

Then we could reply with something like this:

This isn't a good fit for the upstream, because it would require time and resources to work around an unusual problem your organization has created for itself and would benefit very few (and perhaps zero) other organizations. We recommend you focus on merging your two SSO systems instead, since that seems to be the root of the problem, and would resolve this problem (and probably other problems) without any changes in the Phabricator upstream. If you'd like, we can give you a quote for fixing this via extension at consulting rates, which will be large enough that you might be able to get some leverage on getting the root problem fixed, since it could help you demonstrate that not merging the two SSO systems has a concrete cost to your organization.

That scenario may be way off the mark, but it's the most likely scenario I can construct from the information you've actually provided to us.

Thanks for the detailed reply.

I tried to explain the root problem properly, and I did read the "Contributing Feature Requests" and "Describing Root Problems" docs before posting.. but I guess I didn't manage to explain properly after all.

For us it's as simple as: We have a need to link to Phabricator from an internal website, and we prefer to have automatic SSO for the users, so we need Phabricator to provide an URL which automatically initiates OAuth SSO login.

We already have an implementation of this internally, so I guess we'll maintain that ourselves going forward.