1. 21 Sep, 2015 1 commit
  2. 04 Sep, 2015 1 commit
  3. 01 Sep, 2015 1 commit
  4. 27 Aug, 2015 1 commit
    • [LTI Provider] Grade passback for non-leaf blocks. · 9e6c4491
      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
  5. 03 Aug, 2015 1 commit
  6. 08 Jul, 2015 1 commit
    • [LTI Provider] Refactoring to remove the lti_run method · 99fbf4d6
      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
  7. 26 Jun, 2015 1 commit
    • [LTI Provider] Added an authentication backend to log in LTI users · 18734cf0
      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
  8. 12 Jun, 2015 2 commits
    • This change cleans up the work in progress request at #8176 · c3106bc4
      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
  9. 09 Jun, 2015 1 commit
  10. 05 Jun, 2015 1 commit
  11. 03 Jun, 2015 2 commits
    • [LTI Provider] Basic LTI authentication · ee70d459
      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
    • [LTI Provider] Bugfix in LtiConsumer handling code · 71ee9d3b
      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
  12. 02 Jun, 2015 2 commits
    • [LTI Provider] Use LTI Outcome Service to pass back scores · 0fe41374
      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 · b4da8e2b
      Updated LTI render courseware test for courseware-chromeless.html
      Andrew Dekker committed
  13. 27 May, 2015 1 commit
  14. 20 May, 2015 1 commit
  15. 19 May, 2015 1 commit
  16. 28 Apr, 2015 1 commit
  17. 27 Apr, 2015 1 commit
  18. 23 Apr, 2015 1 commit