Paul Tarjan schrieb:
Yes, I'm talking about 5.2.1
For JSONP the user's browser is the client. It will make a request by executing
some HTML like this:
<script
src="http://graph.facebook.com/me?access_token=...&callback=jsonp_cb";></script>
<script>
function jsonp_cb(response) {
if (response.error) {
// error out
return;
}
// do cool things
}
</script>
(this is done instead of an AJAX request, because of cross-domain restrictions).
As to Aaron's point, Google sends 3 parameters to the callback function, which
I kind of like since the user can choose to get the code or not. Something like:
jsonp_cb({
"error": "invalid_request",
"error_description": "An active access token must be used to query
information about the current user."
}.
400,
'Bad Request');
which you can grab with
function jsonp_cb(response, code, status) {
}
or ignore it with
function jsonp_cb(response) {
}
But all of this is outside of the spec. I just want to make sure the spec says
that the HTTP status code can send as 200 if the server+client need it for
errors.
I think this can be achieved in two ways: (a) either the client tells
the server using a parameter or (b) the server always responds with
status code 200 in some cases. From my understanding, status code 200 is
relevant for requests following the rules of section 5.1.2 only. So my
sugesstion would be to go with option (b) and modify the spec to always
return status code 200 for such requests. This keeps the spec simpler
and preserves the behavior of requests following the rules of section
5.1.1..
regards,
Torsten.
Paul
On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote:
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 <[email protected]> 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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
