Signpost 1.2.1.1 maintenance release

Sorry for any inconvenience caused by the Signpost 1.2.1 release last week, which apparently regressed on callback URLs (see issue 34). That’s fixed in 1.2.1.1, along with another bug which prevented custom OAuth authorization headers to not be correctly interpreted before message signing.

Both should work fine now.

Have a nice weekend!

Signpost 1.2.1 released: fixes and features inside!

I just released Signpost 1.2.1, which is mainly a maintenance release, but also contains a couple new features.

Here is what changed:

• OAuthProvider has become more flexible. You can now override even more of its default behavior, e.g. for creating customized requests for the token handshake. I’ve also reduced code duplication by pulling code up from concrete provider implementations to the abstract base class, so you now only need to worry about implementing small, self-contained steps when implementing a custom provider, such as creating a custom request object.
• OAuthProvider now sends token requests using POST, as suggested by the standard. You can change that behavior by overriding createRequest(endpointUrl), but that should hardly be ever required.
• OAuthProviderListener is a new class that allows you to hook into the token handshake and intercept the flow at certain points (e.g. before and after message signing). This makes it easy for you to customize the request that is being sent, e.g. by setting custom headers or parameters. This deprecates setRequestHeader(), which was formerly used to do that, but which was very limited.
• During token handshake, OAuth parameters are no longer being sent in a “mixed” way, i.e. they all go in one place now, depending on which SigningStrategy is used by the consumer. In earlier versions, OAuthProvider would always send the oauth_callback and oauth_verifier in the URL.
• CommonsHttpOAuthProvider can now be configured with a custom HttpClient
• During token handshake, unsuccessful server replies (e.g. 401 or 400) are not being swallowed anymore, instead the response body can now be retrieved from the exception that is thrown and be interpreted by the client.
• The debug output has been extended to include the Authorization header and request URL (note that when using java.net.HttpURLConnection, one cannot read the Auth header for security reasons, and it will always print as null)