问题
I have a jersey oauth provider that uses HmacSHA1 for signing/verifying requests. This works for my development & test platforms where client & server are both different physical systems. However, when I move to a production platform the HmacSHA1 algorithm (provider-side) returns a different value than the HmacSHA1 algorithm (client-side) using the same params & secret, and my oauth validation fails.
The JDK (1.6.x) is the same exact version on both the provider and client for all platforms.
When I switched my oauth provider & client to use the PLAINTEXT signature method (bad for security, I know), it works on all platforms.
When I dug into the jersey OAuthSignature.verify() method, it calls the signature method's (HmacSHA1 or PLAINTEXT) verify function, which simply signs the oauth elements with the secret and compares the value against the signature passed in.
For HmacSHA1, the method calls the Base64.encode() method to generate the signature, but for PLAINTEXT no encoding is done (as expected).
What could be causing the Base64.encode() method using an HmacSHA1 signature algorithm to have different results using the same params & secret on both systems?
Thanks in advance! --TK
回答1:
One educated guess: if platform encodings differ (quite common; some platforms use ISO-8859-1, others UTF-8, Windows maybe CP-1250 or whatever, AND OAuth library in question has newbie bugs where encoding is not specified when converting between byte[] and String, AND there are characters that encode differently on different encodings (usually anything but 7-bit ASCII range, characters 0 - 127), and you will end up with different signatures.
So -- you can see what the platform default encoding is; and force it to be same on both first. If this solves the issue, I would consider reporting this as a bug to OAuth lib (or framework that bundles it) author(s), or at least ask on mailing lists.
I have seen such bugs (String.getBytes("test")) VERY often -- it is one of most common Java anti-patterns in existence. Worst part is that it is bug that only causes issues under specific circumstances, so people are not bitten badly enough to fix these.
Another potential issue is with URL encoding -- handling of certain characters (space, %, +) can differ between implementations, due to subtle bugs in encoding/decoding. So you can see if content that you are passing has 'special' characters; try to see if eliminating them (for testing) makes difference, and zero in what triggers the difference.
来源：https://stackoverflow.com/questions/6388737/hmacsha1-generates-different-signatures-on-different-systems-using-same-secret