Incompatibility with OAuth 1.0a when using commons-codec-1.4

[GoogleCodeExporter]

When using signpost-1.1 with commons-codec-1.4.jar against a server that
requires OAuth 1.0a (linkedin), all requests (i.e. simply getting a request
token) fail with 401 authorization errors:

oauth_problem="signature_invalid"

It works absolutely fine with commons-codec-1.3.jar.  Something is wrong
only when using 1.4.

Original issue reported on code.google.com by dchecko...@gmail.com on 29 Dec 2009 at 11:47

[GoogleCodeExporter]

There was a problem with CC-1.4's Base64 encoder appending a CRLF, hence 
Signpost 
generated wrong signatures with CC-1.4: 
https://issues.apache.org/jira/browse/CODEC-89

I remember committing a workaround for this, by trim()-ing its result.

Can you give me more details about your environment/setup?

Original comment by m.kaepp...@gmail.com on 30 Dec 2009 at 1:36

[GoogleCodeExporter]

Just tested against Twitter and mynameise.com using CC-1.4 and Signpost 
1.2-SNAPSHOT 
(which has seen no changes to message signing compared to 1.1 as far as I 
recall). 
Both work fine for me.

There have been reports about LinkedIn issues before (on the mailing list), 
turning 
out that they do non-conformous stuff when doing OAuth. Are you sure it's not a 
LinkedIn problem?

Can you post a fully executable test case which reproduces the problem you're 
seeing?

Original comment by m.kaepp...@gmail.com on 30 Dec 2009 at 1:49

[GoogleCodeExporter]

Environment/setup: I'm using java 1.6.0_15, doing development on a macbook,
deployment on linux.

Original comment by dchecko...@gmail.com on 30 Dec 2009 at 1:50

[GoogleCodeExporter]

BTW, I saw the exact same thing -- when I tried the same test case against 
twitter it
worked absolutely fine.  Against linkedin, no joy.  My raw test case has long 
since
been wiped out, unfortunately, since I switched to using linkedin-j with
CC-1.3...which is working great.

Original comment by dchecko...@gmail.com on 30 Dec 2009 at 1:52

[GoogleCodeExporter]

I just released Signpost 1.2. Could you please test whether the problem is 
gone? There 
have been a lot of changes to the core implementation for this release.

Thanks.

Original comment by m.kaepp...@gmail.com on 27 Jan 2010 at 10:50

[GoogleCodeExporter]

My code won't even compile with Signpost 1.2.  I don't mean to be dramatic, but 
it
looks like there were several fundamental changes...enough to make me a little
nervous about using this release of signpost-core-1.2.jar with linkedin-j.

For example, the "OAuthTwitterExample" that I used as a reference for doing some
access token stuff no longer even compiles.

Looks like SignatureMethod didn't make it into the jar?

Original comment by dchecko...@gmail.com on 28 Jan 2010 at 12:05

[GoogleCodeExporter]

There have been some minor API changes, aiming to make the more widely used 
parts of the API both simpler 
and play better in service oriented environments.

There's probably only two changes you will notice:

1) There is no SignatureMethod class anymore. That class was bulk, it was only 
used to build a MessageSigner 
object. By default, any OAuthConsumer now uses an HmacSha1MessageSigner, since 
that's what practically 
everyone is using these days. If you want to use another signer, call 
setMessageSigner() on your consumer 
with another signer instance.

2) The consumer is not closely coupled to the provider anymore. Instead, the 
retrieve*Token() methods now 
take the consumer as an argument. This allows to provide message signing and 
token retrieval as loosely 
coupled services.

That's pretty much it. Some APIs have become slightly bigger, but also more 
flexible.

That being said, if 1.1 works well for you, then there is no need to upgrade. 
There have been quite some fixes 
which made it into 1.2 though, so if you experience problems, you should 
upgrade ASAP.

Original comment by m.kaepp...@gmail.com on 28 Jan 2010 at 8:48

[GoogleCodeExporter]

I consider this fixed/not reproducible with the 1.2 release. Tested with 
Twitter and 
CC-1.4.

If you still run into this problem, feel free to reopen, along with code I can 
execute 
to reproduce the issue.

Original comment by m.kaepp...@gmail.com on 7 Feb 2010 at 7:10

• Changed state: Fixed