Hi Liam
On Feb 29, 2012, at 1:52 PM, Liam Lynch wrote:
> Hi amber devs -
>
> I just ran into an issue using the OAuthTokenRequest to interpret a request.
> I noticed that for an authorization code grant type it automatically
> validates that the client ID and secret are there:
>
> public class AuthorizationCodeValidator extends
> AbstractValidator<HttpServletRequest> {
>
> public AuthorizationCodeValidator() {
> requiredParams.add(OAuth.OAUTH_GRANT_TYPE);
> requiredParams.add(OAuth.OAUTH_CLIENT_ID);
> requiredParams.add(OAuth.OAUTH_CODE);
> requiredParams.add(OAuth.OAUTH_REDIRECT_URI);
> requiredParams.add(OAuth.OAUTH_CLIENT_SECRET);
> }
> }
>
>
> However in the spec passing the client ID and secret using BASIC
> authentication seems to be mandatory, whereas it is only optional to support
> passing the credentials via parameters in the body (and is not recommended):
>
> http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-2.3.1
>
> (Note previous v22 of the spec does not say BASIC is mandatory, but using the
> body is still not recommended:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-2.3.1 )
>
> So I was planning on using BASIC and this validation came as a surprise... :-)
>
> Anything I've missed about this or any other suggestions?
> Or if a bug do you think you are likely to fix for the first release?
at the first glance looks a bug to me. How about open a Jira ticket so we can
move forward?
Regards
Antonio
>
> I guess the options are (1) to offer a way to instantiate a OAuthTokenRequest
> that doesn't do this bit of validation (assumes this is taken care of
> elsewhere), this is simplest, or (2) get the details from the request
> authorization header to validate (and provide via getters).
>
> Thanks - and thanks very much for all your work on this project!
>
> Liam Lynch
>
>
> The information contained in this email may contain confidential or legally
> privileged information. If you are not the intended recipient any disclosure,
> copying, distribution or taking any action on the contents of this
> information may be unlawful. If you have received this email in error, please
> delete it from your system and notify us immediately. Any views expressed in
> this message are those of the individual sender, except where the message
> states otherwise. IDBS takes no responsibility for any computer virus which
> might be transferred by way of this email and recommends that you subject any
> incoming E-mail to your own virus checking procedures. We may monitor all
> E-mail communication through our networks. If you contact us by E-mail, we
> may store your name and address to facilitate communication.
