Luke's point still holds true of the core spec needing to allow a 200 status code on an error in this scenario. I'd also rather see this as part of the core spec as it reduces the number of things that implementors will need to read for common use cases.
--David On Tue, Aug 17, 2010 at 9:06 AM, John Panzer <[email protected]> wrote: > Well, no, jsonp is a special transport layer inside http. Making that > fuzzy will cause (interop and security) problems. > > On Tuesday, August 17, 2010, Luke Shepard <[email protected]> wrote: > > 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 <[email protected]>: > >> > >>> 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 < > [email protected]> 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 > > -- > -- > John Panzer / Google > [email protected] / abstractioneer.org / @jpanzer > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
