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
On 09/05/18 11:30 AM, jwint...@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
> 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
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.
On Wednesday, May 9, 2018 at 10:17:40 AM UTC-4, Joshua Winters wrote:
>
> Is there an expectation that all of these providers would/should
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
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
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`
