Loading Profile...
Improper Base64 encoding used in the Spec?
Hi all, hard at work integrating OAuth into Satisfaction and I came across what seems to be a mistake in the spec.
Appendix A.5.2. lists the resulting signature as 'Gcg/323lvAsQ707p+y41y14qWfY' whereas I'm getting 'Gcg/323lvAsQ707p+y41y14qWfY=' from my tests.
Calculating the HMAC-SHA1 digest for the signature base string provided in Appendix A.5.1. I get the 20 bytes:
[25, 200, 63, 223, 109, 229, 188, 11, 16, 239, 78, 233, 251, 46, 53, 203, 94, 42, 89, 246]
When bytes listed above are base64 encoded according to RFC 2045 you get 'Gcg/323lvAsQ707p+y41y14qWfY=', whereas modified-base64 (which leaves out the padding) according to RFC 2152 matches the first version.
Which is correct? The Spec specifically mentions RFC 2045.
Appendix A.5.2. lists the resulting signature as 'Gcg/323lvAsQ707p+y41y14qWfY' whereas I'm getting 'Gcg/323lvAsQ707p+y41y14qWfY=' from my tests.
Calculating the HMAC-SHA1 digest for the signature base string provided in Appendix A.5.1. I get the 20 bytes:
[25, 200, 63, 223, 109, 229, 188, 11, 16, 239, 78, 233, 251, 46, 53, 203, 94, 42, 89, 246]
When bytes listed above are base64 encoded according to RFC 2045 you get 'Gcg/323lvAsQ707p+y41y14qWfY=', whereas modified-base64 (which leaves out the padding) according to RFC 2152 matches the first version.
Which is correct? The Spec specifically mentions RFC 2045.
1
person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
-
Inappropriate?The resulting signature in the spec is incorrect - the padding in this case is important.
There are a few cases where the Base64 encoded signature might not be exactly the same, depending on which Base64 library you're using (specifically, line breaks may or may not be present), but as long as the decoded content is the same, you're good.
I’m thankful
2 people say
this answers the question
EMPLOYEE
