The "oauth_body_hash" appeared twice in the auth header in the request
when posting grade back to tool consumer. However, the signature sent
from edX is calculated based on only one oauth_body_hash.
On the tool consumer side, the signature is calculated based on the auth
header and will use the duplicated fields. So the signatures will not match.
And request will fail the signature validation.
The bug was introduced in this commit:
03cee389e0
on July 12th by updating the oauthlib.
Because 0.7.2(original version) doesn't have oauth_body_hash support, so a custom
OAuth1 client was implemented to add oauth_body_hash to the headers:
f5d0f3ff55/lms/djangoapps/lti_provider/outcomes.py (L24).
However, the new oauthlib 1.0.3 has support for oauth_body_hash
(51675237c4 (diff-c2a1e5f1ddfe8e48ff62b59eb952644eR180)).
So after updating library, oauth_body_hash is added twice.
This fixes the bug by removing the custom client and use the oauthlib
default client to generate the auth header.
Catalog-based MicroMasters need to be displayed in the LMS. However, the LMS currently retrieves all program data from the soon-to-be-retired programs service. Consuming program data exclusively from the catalog service is out of the question right now; it's too complex to confidently pull off in a week. This is a functional middle ground introduced by ECOM-5460. Cleaning up this debt is tracked by ECOM-4418.
* First take at forcing a subsection's grade to update when a signal is
sent that a problem's score has changed
* Refactor signal handler connection.
* Expand bokchoy tests to cover progress page
* Add some grading unit tests
TNL-5394
TNL-5364
We're often grabbing the metadata of a specific thread to then be able
to perform other operations, but we never need the actual responses or
comments of a thread unless we're displaying it in the normal forum
view.
This change sets a default of with_responses=False, which instructs the
comment service to not send back the responses/comments for the given
thread. We only ask for responses in the case of rendering a single
thread or inline discussion.
Catalog-based MicroMasters need to be displayed in the LMS. However, the LMS currently retrieves all program data from the soon-to-be-retired programs service. Consuming program data exclusively from the catalog service is out of the question right now; it's too complex to confidently pull off in a week. This is a functional middle ground introduced by ECOM-5460. Cleaning up this debt is tracked by ECOM-4418.
