I would like to furthermore track down the relevant use cases. Assuming
you are referring to section 5.2.1, how does your client send the access
token to the resource server? I'm asking because I think error handling
for URI query parameters, Body parameters and Authorization headers
could be handled differently. For URI query parameters and Body
parameters, returning the error code in the payload instead of the
status code would be acceptable from my point of view since
authentication is also pushed to the application level. In contrast when
using HTTP authentication, 40(x) status codes together with
WWW-Authenticate are a must have.
Would such a differentiation help you?
regards,
Torsten.
John Panzer schrieb:
Is there ever a case other than jsonp where this is necessary?
On Monday, August 16, 2010, Aaron Parecki <aa...@parecki.com> wrote:
Excellent point. Would it be worth it to include a new error_code
parameter in the JSON response so that clients have a way to get the
http status code from the data available in the jsonp response?
The response in this case might look like this
jsonp_cb({
"error_code": 400,
"error": "invalid_request",
"error_description": "An active access token must be used to query
information about the current 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 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 happens.
For example:
GET /me?callback=jsonp_cb HTTP/1.1
Host: graph.facebook.com <http://graph.facebook.com/>
HTTP/1.1 200 OK
Content-Type: text/javascript; charset=UTF-8
Content-Length: 152
jsonp_cb({ "error": "invalid_request", "error_description": "An active access
token must be used to query information about the current user."
});
would never get sent to the browser if we obeyed the spec and sent it as an
HTTP 400.
---
So, I recommend we add wording to 5.2.1 like:
If the protected resource is issuing a response that requires a different HTTP
status code than the one specified (for example, JSONP), then it MAY use an
alternate HTTP code. The server should make it clear which parameters trigger
this mode so that clients know not to rely on the HTTP status code for error
detection.
Paul_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
