Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persisting provider for use later #49

Open
cheungkonghou opened this issue Oct 28, 2015 · 4 comments
Open

Persisting provider for use later #49

cheungkonghou opened this issue Oct 28, 2015 · 4 comments
Labels

Comments

@cheungkonghou
Copy link

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
Copy link

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
Copy link

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

@SidneyNemzer
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants