POX replaceResult: oauth_body_hash about basiclti-util-java HOT 15 CLOSED

It looks like oauth_body_hash is required by the lti spec (http://www.imsglobal.org/LTI/v1p1/ltiIMGv1p1.html#_Toc319560469), so this should definitely be added.

I believe the method used to generate the oauth_body_hash must be the same as the algorithm in oauth_signature_method In the commit that you linked, it looks like you're using SHA1 instead of HmacSHA1 in order to generate the oauth_body_hash.

When you say it 'breaks signing,' do you mean that Sakai/Moodle rejects the request based on an incorrect oauth_body_hash, or is it something else?

from basiclti-util-java.

I was able to get through oauth_body_hash validation, so I believe the parameter was not being included in the oauth_signature calculation. (It also made Canvas start rejecting the request, so I'm fairly sure.)

from basiclti-util-java.

I was dead wrong about the oauth_body_hash algorithm to use, Keep using SHA1. (http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/oauth-bodyhash.html#anchor3)

If the oauth_signature does not include the oauth_body_hash I would regard it as a bug with oauth-signpost. I'll do some digging as to whether this is actually the case.

Do Moodle and Sakai accept your requests that include oauth_body_hash while Canvas rejects them?

from basiclti-util-java.

I haven't tested against Moodle, but Sakai gave me "Failed to validate: signature_invalid".

from basiclti-util-java.

(It had previously been giving me "Did not find oauth_body_hash", then "Body hash does not match header", as I got it figured out.)

from basiclti-util-java.

And yes, I suspect you're right that it's a bug in oauth-signpost.

from basiclti-util-java.

Perhaps I should just drop the signpost dependency and roll my own, as in https://developer.mastercard.com/portal/display/api/Java+OAuth+Sample+Code .

from basiclti-util-java.

anyone is going to fix this? I just ran into the same issue where oauth_body_hash is not calculated in the request header.

from basiclti-util-java.

Hi @kejd315, thanks for your interest in basiclti-util-java.

It would be useful to hear a bit more about how you're using this library, and where exactly it's breaking in order to help you.

What version are you currently using? Which method are you using to send POX results to the consumer? Are you also implementing against Sakai?

In recent versions, there have been measures added to allow clients to override the default signing implementation, if you choose to use your own.

from basiclti-util-java.

I am using sendReplaceResult() from https://github.com/IMSGlobal/basiclti-util-java/blob/master/src/main/java/org/imsglobal/pox/IMSPOXRequest.java
The method doesn't generate oauth_body_hash in the request header.

from basiclti-util-java.

I've submitted a pull request for the issue, @kejd315 . Sorry for the trouble.

from basiclti-util-java.

If you're curious, @pfgray , the only problem with my previous patch was that I had to URL-encode the hash value. Embarrassing.

from basiclti-util-java.

This is great news. Regarding the body hash algorithm SHA1 you use, should it be HMAC-SHA1
according to LTI 1.1 spec?

from basiclti-util-java.

Thanks for the review! The oauth body hash extension specifies an unkeyed
hash algorithm:

https://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/oauth-bodyhash.html#unkeyed
On Jan 29, 2015 7:16 PM, "kejd315" [email protected] wrote:

This is great news. Regarding the body hash algorithm SHA1 you use, should
it be HMAC-SHA1
according to LTI 1.1 spec?

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

from basiclti-util-java.

Thanks for your quick response. This looks good!

from basiclti-util-java.