-
Notifications
You must be signed in to change notification settings - Fork 44
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Adding extra verification method to support validating requests that …
…may contain arrays, solves #33
- Loading branch information
Showing
4 changed files
with
84 additions
and
16 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
83cabd1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The untyped
Map.Entry
might give callers uncomfortable warnings. I see no harm in accepting aCollection<Map.Entry<String, String>>
or perhapsCollection<? extends Map.Entry<String, String>>
.More importantly, are you sure that the URL can contain query string params? I tried passing the entire URL to
OAuthMessage
, and validation failed. When I instead stripped off the query part and added the query string parameters to the map, it passed. I read through the source code in http://grepcode.com/file/repo1.maven.org/maven2/net.oauth.core/oauth-provider/20100527/net/oauth/SimpleOAuthValidator.java#SimpleOAuthValidator.validateSignature%28net.oauth.OAuthMessage%2Cnet.oauth.OAuthAccessor%29 and was unable to find any part where the query string parameters were stripped off. Of course I could be wrong--that code is not easy to follow.This is all super frustrating to implementors who want to get their pedagogy into an LMS and are less interested in OAuth, so it would be good to get it right.
83cabd1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your input, I've updated the signature to be:
Collection<? extends Map.Entry<String, String>>
.As far as the url containing query string parameters... I've done some preliminary testing and it turns out it works both ways! (in the sense that you can send the url with parameters to
LtiOauthVerifier
, or extract the url parameters and include them in theCollection<Entry<String, String>> params
).I'll update the javadoc in this interface to reflect this, and if I get some time tomorrow, I'll see if I can add some unit tests that reflect the above. I'm also going to create a PR for these changes that you can comment further on if you wish
83cabd1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, that code change looks good.
As for the URL parameters, I can give you a specific set of POST parameters and a URL with a request parameter that I get from Canvas. It does not validate when I pass it as-is to the OAuthValidator, but it does validate when I move the request parameter from the URL to the params collection. I don't want to post the shared secret here; contact me if you'd like to see that.
83cabd1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I've added two unit tests, one where the url parameters are passed in via the url, and one where the url parameters are passed in via the collection of parameters.
Testing LTI signatures is always tricky because they are time-based (i.e. if you have a valid signature from a week ago, it is no longer valid since it should be considered "stale"). The only reliable way I've found is to create a signature via our
Signer
, and validate it with ourValidator
, but then again, this solution is a bit tautological... I'm open to ideas on how to make this better, but I fear a better solution would require changes to signpost.Would you be able to construct a unit test (maybe with a different secret) that demonstrates what you're seeing, or possibly post the code that you're using to test?
83cabd1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this part uses signpost. You can specify what time interval is acceptable to you--just set it to 100 years. That should be ok for unit tests.
I sent you a program that shows the issue.