> When I send in the initial request for a verification code and use this
> return url ...

>     https://d.eevu.it/basecamp_auth?user=04c86d1514822b09d60

> ... I get the return error "Provided redirect_uri is not approved".  When
> I just send ...

>     https://d.eevu.it/basecamp_auth

> ... it works fine.  This matches what i have in the app control panel.
>  But this means the return url is just something like "?code=1234" and I
> don't have my user id.  This is a big problem.  If my server sends
> multiple verification code requests, how is it supposed to know which
> callback matches which request?

> Dropbox allows the query params and I have no problem.

> Hey Mark

> On Fri, Nov 9, 2012 at 9:22 AM, Mark Hahn <ma...@hahnca.com <javascript:>>wrote:

>> Ok, I understand now.  The verification id is only used once for all
>> users.  This is quite different from how dropbox does auth and I was
>> expecting the same.

>> Sorry for the lame question.

>> On Thursday, November 8, 2012 3:43:10 PM UTC-8, Mark Hahn wrote:

>>> When I send in the initial request for a verification code and use this
>>> return url ...

>>>     https://d.eevu.it/basecamp_**auth?user=04c86d1514822b09d60<https://d.eevu.it/basecamp_auth?user=04c86d1514822b09d60>

>>> ... I get the return error "Provided redirect_uri is not approved".
>>>  When I just send ...

>>>     https://d.eevu.it/basecamp_**auth <https://d.eevu.it/basecamp_auth>

>>> ... it works fine.  This matches what i have in the app control panel.
>>>  But this means the return url is just something like "?code=1234" and I
>>> don't have my user id.  This is a big problem.  If my server sends
>>> multiple verification code requests, how is it supposed to know which
>>> callback matches which request?

>>> Dropbox allows the query params and I have no problem.

> We require an exact redirect_uri match. You can pass additional info using
> the 'state' param in the initial auth request. When we redirect back to
> you, we include your original state so you know which user you're working
> with.

> Thanks, it is good to know about the state param..I'm not bitching but
> should I have read about this somewhere in the documentation?

> While I have your attention, I've gotten stuck on the next step of getting
> the token.  I don't know what to put in the body of the POST.  This doesn't
> seem to be documented.

> I've tried sending the POST with an empty body with a Content-Length of
> zero, but I get a 411 saying there is no Content-Length.  As a matter of
> fact I get a 411 no matter what I do.

> Do you know of any sample code that implements these requests?

> On Friday, November 9, 2012 12:55:47 PM UTC-8, Jeremy Kemper wrote:

>> Hey Mark

>> On Fri, Nov 9, 2012 at 9:22 AM, Mark Hahn <ma...@hahnca.com> wrote:

>>> Ok, I understand now.  The verification id is only used once for all
>>> users.  This is quite different from how dropbox does auth and I was
>>> expecting the same.

>>> Sorry for the lame question.

>>> On Thursday, November 8, 2012 3:43:10 PM UTC-8, Mark Hahn wrote:

>>>> When I send in the initial request for a verification code and use this
>>>> return url ...

>>>>     https://d.eevu.it/basecamp_**auth?user=04c86d1514822b09d60<https://d.eevu.it/basecamp_auth?user=04c86d1514822b09d60>

>>>> ... I get the return error "Provided redirect_uri is not approved".
>>>>  When I just send ...

>>>>     https://d.eevu.it/basecamp_**auth <https://d.eevu.it/basecamp_auth>

>>>> ... it works fine.  This matches what i have in the app control panel.
>>>>  But this means the return url is just something like "?code=1234" and I
>>>> don't have my user id.  This is a big problem.  If my server sends
>>>> multiple verification code requests, how is it supposed to know which
>>>> callback matches which request?

>>>> Dropbox allows the query params and I have no problem.

>> We require an exact redirect_uri match. You can pass additional info
>> using the 'state' param in the initial auth request. When we redirect back
>> to you, we include your original state so you know which user you're
>> working with.

> I read the oauth2 draft specification and I see now where the state param
> is defined.  I haven't been able to figure out what goes in the token POST
> request body yet but I'll keep trying.

> On Friday, November 9, 2012 1:22:04 PM UTC-8, Mark Hahn wrote:

>> Thanks, it is good to know about the state param..I'm not bitching but
>> should I have read about this somewhere in the documentation?

>> While I have your attention, I've gotten stuck on the next step of
>> getting the token.  I don't know what to put in the body of the POST.  This
>> doesn't seem to be documented.

>> I've tried sending the POST with an empty body with a Content-Length of
>> zero, but I get a 411 saying there is no Content-Length.  As a matter of
>> fact I get a 411 no matter what I do.

>> Do you know of any sample code that implements these requests?

>> On Friday, November 9, 2012 12:55:47 PM UTC-8, Jeremy Kemper wrote:

>>> Hey Mark

>>> On Fri, Nov 9, 2012 at 9:22 AM, Mark Hahn <ma...@hahnca.com> wrote:

>>>> Ok, I understand now.  The verification id is only used once for all
>>>> users.  This is quite different from how dropbox does auth and I was
>>>> expecting the same.

>>>> Sorry for the lame question.

>>>> On Thursday, November 8, 2012 3:43:10 PM UTC-8, Mark Hahn wrote:

>>>>> When I send in the initial request for a verification code and use
>>>>> this return url ...

>>>>>     https://d.eevu.it/basecamp_**auth?user=04c86d1514822b09d60<https://d.eevu.it/basecamp_auth?user=04c86d1514822b09d60>

>>>>> ... I get the return error "Provided redirect_uri is not approved".
>>>>>  When I just send ...

>>>>>     https://d.eevu.it/basecamp_**auth<https://d.eevu.it/basecamp_auth>

>>>>> ... it works fine.  This matches what i have in the app control panel.
>>>>>  But this means the return url is just something like "?code=1234" and I
>>>>> don't have my user id.  This is a big problem.  If my server sends
>>>>> multiple verification code requests, how is it supposed to know which
>>>>> callback matches which request?

>>>>> Dropbox allows the query params and I have no problem.

>>> We require an exact redirect_uri match. You can pass additional info
>>> using the 'state' param in the initial auth request. When we redirect back
>>> to you, we include your original state so you know which user you're
>>> working with.