Re: [go-nuts] Re: Busted auth providers

2018-05-09 Thread jwinters 
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?


On Wednesday, May 9, 2018 at 2:16:59 PM UTC-4, David Collier-Brown wrote:
>
> 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
>
> -- 
> David Collier-Brown, | Always do right. This will gratify
> System Programmer and Author | some people and astonish the 
> restdav...@spamcop.net|  -- Mark 
> Twain
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Busted auth providers

2018-05-09 Thread David Collier-Brown 

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 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

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

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Busted auth providers

2018-05-09 Thread jwinters 
 

> 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?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Busted auth providers

2018-05-09 Thread jwinters 
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 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.
>
>
> On Wednesday, May 9, 2018 at 8:43:56 AM UTC-4, David Collier-Brown wrote:
>>
>>
>>
>> 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 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Busted auth providers

2018-05-09 Thread 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

On 09/05/18 10:17 AM, jwint...@pivotal.io wrote:
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.



On Wednesday, May 9, 2018 at 8:43:56 AM UTC-4, David Collier-Brown wrote:



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

--
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+unsubscr...@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

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Busted auth providers

2018-05-09 Thread jwinters 
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.


On Wednesday, May 9, 2018 at 8:43:56 AM UTC-4, David Collier-Brown wrote:
>
>
>
> 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 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Busted auth providers

2018-05-09 Thread 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 
   

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.