- 21 Sep, 2015 1 commit
-
-
Nimisha Asthagiri committed
-
- 04 Sep, 2015 1 commit
-
-
Calen Pennington committed
-
- 01 Sep, 2015 1 commit
-
-
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
David Ormsbee committed
-
- 27 Aug, 2015 1 commit
-
-
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.
Phil McGachey committed
-
- 03 Aug, 2015 1 commit
-
-
Ned Batchelder committed
-
- 08 Jul, 2015 1 commit
-
-
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.
Phil McGachey committed
-
- 26 Jun, 2015 1 commit
-
-
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.
Phil McGachey committed
-
- 12 Jun, 2015 2 commits
-
-
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.
Phil McGachey committed -
Ben Patterson committed
-
- 09 Jun, 2015 1 commit
-
-
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.
Phil McGachey committed
-
- 05 Jun, 2015 1 commit
-
-
Nimisha Asthagiri committed
-
- 03 Jun, 2015 2 commits
-
-
This change cleans up the work in progress request at https://github.com/edx/edx-platform/pull/8176 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.
Phil McGachey committed -
The line below was left in during the refactoring shuffle from PR #8205, and causes an issue in a corner case where an LTI launch provides an instance GUID where there wasn't one already set for the consumer. This change fixes the bug, and adds a test to prevent it from recurring.
Phil McGachey committed
-
- 02 Jun, 2015 2 commits
-
-
This change allows the LTI provider to pass grades back to the campus LMS platform using the LTI outcome service. For full details of the outcome service, see: http://www.imsglobal.org/LTI/v1p1/ltiIMGv1p1.html In brief, the LTI 1.1 spec defines an outcome service that can be offered by an LTI consumer. The consumer determines whether a score should be returned (in Canvas, this means that the LTI tool is used in an assignment, and the launch was performed by a student). If so, it sends two additional parameters along with the LTI launch: lis_outcome_service_url: the endpoint for the outcome service on the consumer; lis_result_sourcedid: a unique identifier for the row in the gradebook (i.e. the tool/student/assignment combination). The LTI Provider launch view detects the presence of these optional fields, and creates database records for the specific Outcome Service and for the graded LTI launch. Later, when a score on edX changes (identified using the signal mechanism from previous LTI Provider pull requests), a Celery task is launched to pass the score back to the LTI consumer.
Phil McGachey committed -
Updated LTI render courseware test for courseware-chromeless.html
Andrew Dekker committed
-
- 27 May, 2015 1 commit
-
-
Phil McGachey committed
-
- 20 May, 2015 1 commit
-
-
Phil McGachey committed
-
- 19 May, 2015 1 commit
-
-
Sarina Canelake committed
-
- 28 Apr, 2015 1 commit
-
-
Phil McGachey committed
-
- 27 Apr, 2015 1 commit
-
-
Phil McGachey committed
-
- 23 Apr, 2015 1 commit
-
-
Phil McGachey committed
-