Remove deprecated SingleSectionGrader. TNL-5987
Remove display_name and module_id from Scores objects
Update CourseGradeFactory.__init__ to not be user-specific
Update some callers to use CourseGrade class instead of "summary" dict
Remove no longer needed course_grades.py module.
Renamed django signal from GRADES_UPDATED to COURSE_GRADE_CHANGED
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.
This is necessary to properly implement the LTI outcome passback
spec. It was not included previously because it was causing problems
with Canvas, but Blackboard will not accept outcomes unless they are
properly signed.
The requests_oauthlib doesn't support the body hash spec out of the
box, so BodyHashClient needed to be made. Fortunately, it's a pretty
simple spec:
https://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/oauth-bodyhash.html
This change allows graded assignments to be added to a campus LMS
regardless of the granularity at which the problem sits. Previously
a grade could only be returned if the usage ID for the problem itself
was specified in the LTI launch.
The code assumes that courses taking advantage of this functionality
are arranged in a hiearchy (with sections being parents to verticals,
and verticals being parents to problems). When a grading event occurs
it traverses the parent hiearchy to identify any previous graded LTI
launches for which the new scoring event should generate a grade
update. It then calculates and sends scores to each of those outcome
services.
Since grade calculation is an expensive operation, the code optimizes
the case where a problem has been added only once as a leaf unit. In
that case it is able to behave as before, just taking the grade from
the signal without having to calculate grades for the whole course.
This change is a follow-up to the chages in PR 8347, which removed the
edX login page from the workflow for a new user. Where previously we
redirected a user to the login page, PR 8347 instead creates a new user
transparently and logs them in.
The initial reason for splitting the LTI view between lti_launch and
lti_run was so that there was a target for the GET request that
followed the login page. Since we no longer use the login page, we
no longer need the second view. We also don't need to store the LTI
parameters in the session any more, since they are not persisting
between calls. This simplifies the view logic significantly.
The other change here is to fetch the LtiConsumer object early in
the view, and pass it to the SignatureValidator and scoring system.
When the views were split, this required multiple DB hits for the
same data; we're now only fetching it once.
This change adds a Django authentication backend which, when installed
will authenticate users based on their LTI identity rather than using
a username/password combination. The authentication method determines
first whether a user with the given username exists and, if so, whether
that user is associated with an LTI identity. It also verifies that
the LTI consumer and user ID passed to the LTI launch match those
stored in the LtiUser table. This will always be the case if the
authentication backend is reached through the LTI code, but it
provides an extra guarantee if the backend is called from elsewhere.
This is an initial authentication implementation that allows LTI users to
log in transparently to edX. The behavior is driven by pilot users at
Harvard; this was the most requested feature.
The patch creates a new database model that maps users' LTI identifiers
to newly-created edX accounts. If an LTI launch comes in with a user_id
field that is not in the database, a new edX account is created with a
random user name and password. This account is then stored in the
database, so that it is permanently associated with the LTI user ID.
This patch takes a simplistic approach to session management. If a user
is logged in with a different account when they perform an LTI launch,
they will be logged out and then re-logged in using their LTI account.
In order to keep the patch simple, I have split out some refactoring
that needs to be done into a separate branch that I'll post once this
has been merged. Since we no longer redirect to the login page, we don't
need to maintain two separate LTI endpoints (one for the LTI launch and
one for authenticated users), or deal with the session management that
requires. There are also multiple fetches of the LtiConsumer object
(one in the view, one in the signature validation) that the later
patch will consolidate into one.
This branch fixes the previous conflicts with the test refactoring
carried out in PR 8240.
Change https://github.com/edx/edx-platform/pull/8240 refactored the LTI
provider template rendering code and introduced an issue where a user was
required to be enrolled in a course before that course's content could be
accessed over LTI. According to the LTI design spec:
https://docs.google.com/document/d/185hdPvIxcKtiDOLjb4sTGovA_WYXWz5Cd79gCzQwBms
we delegate access control over LTI content to the LTI consumer, rather
than requiring that users enroll in edX courses explicitly (and that admins
keep edX and LTI provider enrollemnts consistent when students add or drop
courses).
This change fixes the immediate issue, which is disrupting the LTI Provider
pilot currently running at Harvard.
