Busted auth providers

[jwin...@pivotal.io]

It seems like `https://www.gitlab.com` needs to be added to the list of busted auth providers in golang/oauth2.

Instead of maintaining a list of these providers, can we just send the `client_id` and `client_secret` in both the auth header and the body with every request?

[David Collier-Brown]

On Tuesday, May 8, 2018 at 12:22:39 PM UTC-4, Joshua Winters wrote:

It seems like `https://www.gitlab.com` needs to be added to the list of busted auth providers in golang/oauth2.

Instead of maintaining a list of these providers, can we just send the `client_id` and `client_secret` in both the auth header and the body with every request?

That does encourage them to leave it broken...

Can we perhaps detect the problem and refer the developer to

• the public list of bad actors
  
• the workaround 
  

[jwin...@pivotal.io]

Is there an expectation that all of these providers would/should change their implementation? It seems like there are enough reputable implementations that maybe the "broken" case should be better supported, even if the spec discourages it.

I known there's been a long discussion about this already. But it seems like that was all decided a while ago and wondering if things have changed given how long that list of busted auth providers is getting.

[David Collier-Brown]

That's really a question for the oauth principals: if they say "don't do that" and the customers don't listen, they have a problem to either fix or add to the spec as supported. 

We're innocent victims (;-)) and need to decide if we're supporting the spec or the customers.  Right now we're supporting the spec.

--dave

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/iYrYz8YZuPM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net           |                      -- Mark Twain

[jwin...@pivotal.io]

The other thing worth noting is that gitlab can be self-hosted. So I'm not sure how it can even work under the current setup when the domain isn't static.

[jwin...@pivotal.io]

 

We're innocent victims (;-)) and need to decide if we're supporting the spec or the customers.  Right now we're supporting the spec.

I mean you've already decided to support a specific list of customers who don't adhere to the spec. So you're kind of already supporting both. Why not just make it easier?

[David Collier-Brown]

On 09/05/18 11:30 AM, jwin...@pivotal.io wrote:

 

We're innocent victims (;-)) and need to decide if we're supporting the spec or the customers.  Right now we're supporting the spec.

I mean you've already decided to support a specific list of customers who don't adhere to the spec. So you're kind of already supporting both. Why not just make it easier?

I read the existence of a list as a warning to people who attempt to follow the spec that they will needed a workaround for a particular group.  If we were supporting the "won't do" customers, we would presumably have changed our defaults instead.

--dave

[jwin...@pivotal.io]

To be honest, when I look at the names on that list, I really don't see it as much of a warning. The first entry is google. Add that to fact that the spec basically reads "hey we know this use-case exists, we don't recommend it, but acknowledge that some people will have valid reasons to do this", and I still think it should be better supported.  But that's fine different opinions and all.

From a more practical perspective, in the current system, how would I go about getting this to work with a self-hosted service, where the domain name isn't known ahead of time, and can't be whitelisted?

[Wim Lewis]

On 8. maí 2018, at 8:53 f.h., jwin...@pivotal.io wrote:
> It seems like `https://www.gitlab.com` needs to be added to the list of busted auth providers in golang/oauth2.

At the very least, has this been entered into gitlab's bug tracker? The best outcome would obviously be for gitlab to be fixed. Someone who cares about oauth2 and gitlab could check if the problem is listed in the relevant bug tracker(s) and add it if not.

Possibly here: https://gitlab.com/gitlab-org/gitlab-ce/issues

Or maybe the tracker for one of the libraries gitlab uses (doorkeeper?)

[jwin...@pivotal.io]

Just filed an issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/46214

[jwin...@pivotal.io]

It's little embarrassing how long I spent looking at internal/token.go and totally missed this part.