I like splitting on space like scopes. But I'm fine with registering all
possible compositions that make sense, if you prefer.
As I posted to the group about a month ago, we are planning on supporting
response_type=none
response_type=code
response_type=token
response_type=signed_request token
Hi fellow OAuthers,
As we discussed at the meeting there are a few extensions that we'd like
to implement. To do this, we'd like the response_type to be extensible. We
are proposing two new values. none and signed_request token (and
token signed_request for symmetry). Or if you want to turn
At Facebook we issue an HTTP 400 with invalid_request as the error.
http://graph.facebook.com/me?access_token=blahclient_id=150629244948164
(the client_id is to enable draft-10 error messaging).
Without client_id you get a different error message (JSON as well, but
not OAuth2 compliant).
for this field.
Best,
On 9 sept. 2010, at 20:43, Paul Tarjan wrote:
Hi Fellow OAuthers,
We just updated our Graph API's OAuth2 implementation to be draft 10
complaint. Yay!
Well, I should say we are pretty close to draft 10. Some places we differ:
* For now errors
user.
});
Aaron
On Sun, Aug 15, 2010 at 10:16 PM, Luke Shepard lshep...@facebook.com
wrote:
+1
On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote:
Hi Fellow OAuthers,
If a resource wants to return data via the JSONP mechanism then it MUST
return an HTTP 200 error code, or else
Hi Fellow OAuthers,
If a resource wants to return data via the JSONP mechanism then it MUST return
an HTTP 200 error code, or else the browser won't actually call the callback.
The OAuth spec as it stands requires HTTP 400 or 401 or 403 on errors which
won't ever tell the client that an error
Hi OAuthers,
First of all, I think I should introduce myself. I work at Facebook on the
Platform team (anything not facebook.comhttp://facebook.com). Before this I
was at Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth
applications and libraries, both at Yahoo and in
We don't think base64url will work, because the most common error we'll see
is that developers forget the url part and just do plain base64, and
that's not sufficient because the stock set includes +.
I think forgetting to url-decode is more likely than doing the wrong base64
encoding.
