brokenAuthHeaderProviders - time to try something else?

[philpearl]

Perhaps add a BrokenAuthHeader to EndPoint?

The server bug behind this seems pretty common (it's also in Shopify, with domain names [shop].myshopify.com), and it seems unfortunate to need to update this library every time someone finds one. I'd bet 90% of the forks are to add another broken provider.

Let me know if you might accept a change like this and I'll work on it.

[rakyll]

The exported APIs shouldn't reflect that we have workarounds for buggy implementations. If there are any alternative solutions we can consider without touching the APIs, I would like to hear. A wildcard match might more be useful, why don't we convert the brokenAuthHeaderProviders into a regex list?

[philpearl]

Unfortunately the world is buggy... I'd think the API should reflect whatever is useful to operate in the world as we find it. I don't think a regex list would help particularly - you'd still need a code change to deal with a new site.

I can't see why you're happier to make code changes for every site with this bug than to make a single small code change to cope with all of them.

[rakyll]

you'd still need a code change to deal with a new site.

We're fine with maintaining the list for now.

The world may be buggy, but the users don't have to know about it. This package is a higher-level implementation of OAuth 2.0. Most of our users don't even truly know the spec and how OAuth 2.0 works. Exporting an API to turn on/off a workaround is unlikely to be user-friendly.

[philpearl]

I in no way agree with you, but its your project and I'm very grateful for it.

Please add [shop].myshopify.com to the list. The host name varies by shop, but no other change is required to get it to work.

[rakyll]

cc/ @bradfitz

Brad, do you think it might be worthy to export the busted provider's list, so the users can modify it?

Additional to the current bug report, our current solution doesn't help for those who can't upstream their domain names to the list for various reasons such as confidentiality.

[bradfitz]

I like the List Of Shame and a simpler API.

The latency to add to the List Of Shame should put pressure (directly or indirectly) on servers to comply with specs.

[flexd]

This is a very common problem sadly.. please add slack.com to the list of badly implemented APIs.

I like the clean API, but being able to append a host to the list at runtime or toggle the authheader manually would make this library usable.
Off-topic:
Alernatively, @rcrowley could you or someone else at Slack just fix your OAuth implementation?

[philpearl]

I think that's a Shame. And one of the most charmingly passive-aggressive attempts to get something fixed I've seen in a long time. Are you lobbying other OAUTH implementations to add a similar hidden list? Or perhaps your scheme is further along than I imagine and every language has an OAUTH implementation with a secret internal list of naughty hosts? That will show them.

Unfortunately, for the shorter, unqualified entries, once a service is on the list they can't then fix their implementation without adding a new domain name. Perhaps you should at least ask for prefixes with some amount of path.

[bradfitz]

Maybe the community should do something like publicsuffix.org with a shared list of sites which have quirks. I don't know.

The Go community values simplicity. This is an experiment to see if we can have both simplicity and still work. It's an ongoing experiment.

[philpearl]

Moving this configuration to a flag in the Endpoint doesn't feel to me less simple than a hard-coded list. I tried it in my own fork (https://github.com/philpearl/oauth2) and it feels quite nice. If the Endpoints are defined in the repo like the github, etc, ones are then the end-user interface is no more complex.

[ernesto-jimenez]

The latency to add to the List Of Shame should put pressure (directly or indirectly) on servers to comply with specs.

@bradfitz @rakyll unfortunately, I think it puts more pressure on the people consuming non-compliant servers than on the servers themselves.

This is penalising the package users, rather than the servers.

With that being said, I understand your point for not adding workarounds for non-compliant APIs, but at least this should be documented and warned in the package. Current usability means developers try to use the package, it fails, and then they dig into the package's source and find the internal whitelist.

If we are talking about better developer experience, in my opinion it would be better to clearly document the issue. I would also suggest for dropping the internal whitelist at all since the same non-compliant implementation might work or not depending on an internal whitelist most developers are not aware of.

[bradfitz]

Has anybody explored auto-detecting this condition?

[ernesto-jimenez]

@bradfitz IMHO, auto-detecting the condition would enable people building non-compliant providers. I think it should be very clear when a provider is broken rather than working around those silently.

@rakyll @bradfitz

I agree it should be very clear when a provider is broken so we can put some pressure on the server. However, in my opinion OAuth consumers should not be forced to fork the package in order to consume APIs from non-compliant providers.

I would suggest:

• Adding an exported field Config to assign function that builds the http.Request to be used when retrieving a token
• Give it a long name that highlights using that config option means the provider is broken. e.g: BrokenProviderRetrieveTokenHTTPRequest
• When config.BrokenProviderRetrieveTokenHTTPRequest is nil, use the spec-compliant http request.

This way, anybody working around a non-compliant provider can clearly see it's broken and we are not making it easy for them to do such integration. That would make it very clear the provider is broken and might help putting some pressure on the providers.

Ideally, the current internal whitelist would be removed and there would be no exception. Unfortunately, that would probably break applications depending on this package.

Here's a quick implementation

[philpearl]

@ernesto-jimenez it makes more sense to have a flag on the Endpoint as this behaviour varies with the Endpoint, not a particular configuration using/connecting to the Endpoint

[ernesto-jimenez]

@philpearl I didn't pay much attention to naming and where in the Config the field should be. I agree it would probably make sense to have it in Endpoint.

In my opinion, it might still be better to make integrating non-compliant providers a bit awkward rather than just setting up a flag. Integrating a provider that follows the spec would be seamless, but integrating one that doesn't would feel a bit more wrong and the person integrating it would need to learn what the difference is.