#2 makes most sense to me
On Thu, Jul 1, 2010 at 9:03 AM, Justin Richer wrote:
> #2 is the best route forward. If a particular extension requires its
> parameters to be present and handled, then it has a few different
> options. One is breaking at the server side, either with an explicit
> error
I already implemented 09 but it was a (very tiny) bit of a hassle to
have to convert underscores.
So I also agree with 3 except headers
On Thu, Jul 1, 2010 at 2:41 AM, Lukas Rosenstock
wrote:
> 3 except headers.
>
> 2010/7/1 Eran Hammer-Lahav :
>> First, sorry about this. J
>>
>>
>>
>> I do my
I found one small error in 3.1 for the "code" parameter. It mistakenly
says "token" and not "code":
http://r6.sharedcopy.com/6bnqq8v
Anyway I hadn't seen any of the changes since 2.05 which I just
implemented for the Ruby on Rails OAuth Plugin and I have to say the
changes look great. I will have
+1 for #3
Since google implemented I always thought it an elegant simple way of
requesting access.
On Fri, Apr 30, 2010 at 4:52 PM, Joseph Smarr wrote:
> I also vote for #3. I think our field experience has shown that a) lack of a
> standard place to stick scope info in access token requests lea
n traction before the protocol is even out the door. (You just know that
>> people will implement things "like facebook")
>>
>> On Thu, Apr 29, 2010 at 8:24 AM, Pelle Braendgaard
>> wrote:
>>>
>>> Just working on adding OAuth 2.0 support to th
Just working on adding OAuth 2.0 support to the Ruby OAuth Plugin and
I noticed that the facebook documentations says to use the
access_token parameter like this:
https://graph.facebook.com/me?access_token=...
(http://developers.facebook.com/docs/authentication/)
But in the specs it specifies t
