omsmith / ims-lti

A node.js library implementing the IMS LTI tool providers' standards
Other
111 stars 94 forks source link

Persisting provider for use later #49

Open cheungkonghou opened 8 years ago

cheungkonghou commented 8 years ago

Hi there, May I know is there any way to persist the provider for use later (such as saving it in a database) so that I can use the outcome service to submit the grade a few hours later? By the way will the Express request object be detached from signature verification and what alternative can be used? Thanks

nleoutsa commented 7 years ago

We've simply stored the launch request in session and used it to recreate the provider on subsequent requests.

If you decide to go this route, you will need to handle the circular references in the req. A library like https://github.com/isaacs/json-stringify-safe will do this for you.

Note: This has been working great for non SSL requests, but the provider.valid_request method is failing with an "Invalid signature" error when we recreate the provider in this way. This is after a successful SSL launch (We initially had the same error on launch, but followed suggestions in https://github.com/omsmith/ims-lti/issues/4 to debug it).

nleoutsa commented 7 years ago

Update regarding SSL note above: The second validation succeeds after using the hmac-sha1 code found in https://github.com/omsmith/ims-lti/pull/43.

SidneyNemzer commented 7 years ago

Any updates on this?

Currently we're just sticking the req.body into our database, then when a score needs to be sent, retrieving it and creating a provider using Provider#parse_request. That doesn't seem to be an officially documented function, so I have to imagine there's a better way to do it.

SidneyNemzer commented 7 years ago

Actually, after looking through the LTI 1.1 standard and the source of this library, it looks like the only fields necessary to send an outcome are the oauth_consumer_key, lis_outcome_service_url, and lis_result_sourcedid. And the secret, of course, but that's not part of an LTI request.

This library exposes the constructor of the OutcomeService , so you can do this:

const lti = require('ims-lti')

// Load the correct session object, which should contain at 
// least those three required fields
const session = loadLtiSession(/* id? */) 
// The "consumers" object is structured where the key is a 
// consumer key and the value is the secret
const consumers = loadLtiConsumers() 

const outcome = new lti.OutcomeService({
  consumer_key: session.oauth_consumer_key,
  // We can assume the secret exists because the request should have already been validated
  consumer_secret: consumers[session.oauth_consumer_key],
  service_url: session.lis_outcome_service_url,
  source_did: session.lis_result_sourcedid
})

outcome.send_replace_result(1.0, (error, result) => { /* handle result or error */ })

That means you can 'persist' a request by simply storing the oauth_consumer_key, lis_outcome_service_url, and lis_result_sourcedid. When it's time to send the outcome, retrieve these and directly construct an OutcomeService.