Persisting provider for use later about ims-lti

[SidneyNemzer]

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.

[nleoutsa]

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 #4 to debug it).

[nleoutsa]

Update regarding SSL note above: The second validation succeeds after using the hmac-sha1 code found in #43.

[SidneyNemzer]

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.