So does this mean that supporting multiple protocols ends is in conflict with allowing use of POST parameters?
> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Eran Hammer-Lahav > Sent: Thursday, July 01, 2010 1:28 PM > To: Marius Scurtescu; Justin Richer > Cc: [email protected] > Subject: Re: [OAUTH-WG] Support for query/body parameters > (Was Re: Versioning) > > I think all servers must support the header. I don't think we > can demand all servers to support query or post parameters as > that can conflict with their existing namespace or > architecture. I suggest we: > > 1. Make the "Token" scheme required in all resource servers > 2. Allow resource servers to support the URI query or > response body 3. Specify that when a request comes without > the header to a server only supporting the header, the server > should respond with error=authentication_required to inform > the client this form of authentication is not supported. > > EHL > > > -----Original Message----- > > From: [email protected] > [mailto:[email protected]] On Behalf > > Of Marius Scurtescu > > Sent: Thursday, July 01, 2010 12:48 PM > > To: Justin Richer > > Cc: [email protected] > > Subject: Re: [OAUTH-WG] Versioning > > > > On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer > <[email protected]> wrote: > > >> > OAuth tokens as a form-encoded element in a post body? > Yes. Keep it. > > >> > > >> Just curious. What use case would require that the > access token is > > >> put in the post body as opposed to an http header when > accessing a > > >> protected resource? > > > > > > If nothing else, it parallels the use case of a GET-style query > > > parameter. It makes sense to have it be valid in both > ways to allow > > > developers to put the token in with whatever other parameters > > > they're passing along. I've got plenty of use cases here for the > > > query > > > parameters: it's needed for cases where your client can't get any > > > deeper into HTTP than "hey go fetch me this URL". > > > > You can still use query parameters with POST. > > > > > > > What use case says we shouldn't do POST parameters like that? A > > > server wanting to do early-dispatch of a request was > brought up, but > > > that was only in the case of handling OAuth 1 and 2 > simultaneously > > > as I understood it. If a server's going to be doing > dispatch on auth > > > headers and query parameters already, it seems that it's got the > > > wherewithal to parse a form-encoded body, too. > > > > Parsing the body is not trivial. Some filters do not have > access to it > > (apache mod_redirect for example), some frameworks will > allow you to > > access it once and then commit to a format, a decision that > cannot be > > made by a filter (in Java see ServletRequest: > getInputStream vs getReader vs getParameter). > > > > > > Marius > > _______________________________________________ > > 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
