>From the perspective of OAuth, a JSONP endpoint is just another protected >resource. I'd rather not need us to write an extension for every type of >protected resource we might need to access.
I think the wordsmithing you discussed is what Paul's proposing - just saying essentially "look, these are the HTTP error codes you can expect, but it's okay for the server sometimes to give 200 on an error response anyway". That would be necessary even if we wrote an extension. On Aug 17, 2010, at 12:43 AM, Torsten Lodderstedt wrote: > Good point. The server will have to provide special JSONP support anyway. > This is the only place where the requested status code handling is needed. > > +1 for a JSONP extension spec > > This might also result in much cleaner JSONP support. > > regards, > Torsten. > > Am 17.08.2010 um 09:28 schrieb John Panzer <jpan...@google.com>: > >> Except you cannot guarantee that result of course (proxies, apache >> plus tomcat separate processes etc. will all result in error codes). >> >> Doesn't this all depend on a jsonp extension in the first place - the >> client has to request a special jsonp response by specifying the >> callback, thus making the server both use 200s where possible and also >> wrap its response data in a callback call? That's not part of the >> spec either, why not just define both pieces of behavior in a jsonp >> extension spec? (Assuming this can be done without violating the >> letter of the core spec, which might take some wordsmithing.) >> >> On Monday, August 16, 2010, Torsten Lodderstedt <tors...@lodderstedt.net> >> wrote: >>> 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 <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 >>> >>> >>> >>> >>> >>> >>> >> >> -- >> -- >> John Panzer / Google >> jpan...@google.com / abstractioneer.org / @jpanzer > _______________________________________________ > 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
