This repository was archived by the owner on May 13, 2022. It is now read-only.
Added "replaces" property and pre-bencode normalization #11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I started this by adding a new "replaces" property to handle document replacement. I refactored property initialization into a private helper function and added a new constructor signature so that users could optionally provide a String array of IDs to replace and leave the existing constructors intact.
However upon testing I found that documents must pass signature verification otherwise the Learning Registry node will reject the submission. This applies both for the document that is being submitted and the one that is being replaced. The hash computations coming out of LRJavaLib and the LRSignature module in the Learning Registry server software were different, and I tracked it down to the omission of a normalization step, per the spec here:
http://docs.learningregistry.org/en/latest/spec/Identity_Trust_Auth_and_Security/index.html#signing-a-resource-data-description-document
The main issues were String conversion of booleans and dropping of numeric values. Note however that the spec says that all numeric values should be dropped but the actual Python implementation only drops numeric values in arrays, so I copied the implementation so as to work properly with real-world servers. I've tested against the LR sandbox and have set up integration tests for our project which depends on LRJavaLib, but have not added any unit or integration tests to LRJavaLib proper.
While I was in there, I also refactored the generation of signable and sendable data maps -- these are essentially the same modulo signing information and excluded fields, so I thought it best to have one defer to the other for the sake of DRY.