This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

OAuth 1 parameter transmission oauth_signature URL encoding

Sep 25th, 2012, 10:07 AM

I am having an issue with the OAuth not URL encoding oauth_signature for transmission using request URI query with version 1.0.0.RC2. The OAuth specification says it should be encoded but that does not seem to be happening.

The problem occurs most commonly when the oauth_signature parameter in the URL contains a "+". This is converted to a space by the server and the signature, which then causes the signatue that is calculated by the server to differ, for example:

Comment

After I posted I found a reference in the documentation of some code on the spring social site that referred to the same problem.

I have a possible solution that I am testing now, I have written a sub class for HMAC_SHA1SignatureMethod class that url encodes the signature. You also need to write a sub class for the CoreOAuthSignatureMethodFactory and some other sub classes to insure it is used. There I will post the code once I am confident it works.

Bart.

Comment

I wrote 2 new classes: a decorator class that implements the OAuthSignatureMethod interface and a sub class of the CoreOAuthSignatureMethodFactory class. The decorator simply URL ecodes the String retruned by the sign method and the factory sub class wraps the OAuthSignatureMethod object returned by the getSignatureMethod method of the super class.

You need to make an additonal call on the OAuthRestTemplate in the client or it will not use the new CoreOAuthSignatureMethodFactory sub class. This is the call to:

restTemplate.setRequestFactory(requestFactory);

I would have thought that putting both the ProtectedResourceDetails and OAuthConsumerSupport in the OAuthRestTemplate would have been enough but apparently not.

Comment

That's potentially really useful. Are you suggesting that these should be the default implementations of those strategies? Are there any test cases? (Please also read the contributor's guidleines in the README.)

Comment

I do not have enough experience with OAuth or knowledge about the specification to say with confidence that it should be the default. My quick reading of the relevant sections of the 1.0a specification is that the signature should be URL encoded if you are using the URL transmit the OAuth parameters, not sure that would work if you are using the authorisation headers or body to transmit the parameters.

The one thing that did surprise me and initially made me think this would not work is the the SignatueMethod is not used unless you make a OAuthClientHttpRequestFactory with the call:

Then add that to the OAuthRestTemplate, despite the fact the the OAuthConsumerSupport was already being added to the OAuthRestTemplate. If you are setting the OAuthConsumerSupport on the OAuthRestTemplate I would expect the default OAuthClientHttpRequestFactory to use it. The alternative might be to have a constructor where you can add the OAuthConsumerSupport but then you should probably remove the setter for that attribute. I think it would then conform to the principle of "least astonishment" a little better.