Add a method to get the complete token for system background functions

Is your feature request related to a problem? Please describe. Creating line items (usually grade items/assignments) may take some time due to performance of a remote LMS (the platform) and a large number of activities. So we have to queue these tasks up and execute them in the background. However, to create line items we have to pass in the “token” from the request via the lti.onConnect() handler. We are storing that right now from when we make the initial association because the following call does not return platformContext: await lti.Database.Get(false, 'idtoken', {id: specData.idTokenId, iss: idTokenResult.iss, clientId: idTokenResult.clientId, deploymentId: idTokenResult.deploymentId, user: idTokenResult.user}). platformContext seems needed for createLineItem.

Describe the solution you’d like We are looking for a best practices using the library to make calls on behalf of a user that may not be logged in - such as background processes. (In our case the instructor make the initial association of resources). If the best practice is using the full token then a method to restore the whole thing.

Describe alternatives you’ve considered As described above we are storing the token when associating a platform and resources on our side.

[Cvmcosta]

Hello @scalebig!

LTI 1.3 Consumers generate service URLs (for memberships, lineitems and scores) based on the specific context of the launch.

Ltijs stores a contexttoken object for each launch context, so in order to retrieve a specific contexttoken and the Services URLs in it you would need to know the context identifier for it (built with: platform, Client ID, deployment ID, Course ID, and Resource ID), so if you need all of this information to retrieve the complete tokens without an ltik (Where this information is stored during in a regular launch context), you might as well just store the entire ID Token.

I am working on another project that requires queued LTI tasks and that is also how i solved this issue. It’s important to have in mind that that is not how LTI 1.3 is intended to be used, the ID Token information is not supposed to be treated as reliable for a very long time after the initial launch since it’s Service URLs are generated dynamically by context.

If you don’t want to save the entire ID Token, you can just save { iss, clientId, user, platformContext }, this is usually enough to call any of the service methods.

It’s important to remember that you need to store this object for every launch if the user ID is relevant. If it is not you can get away with storing the object for every new contextID (idtoken.platformContext.contextId).

You can also get the idtoken.platformContext object from the res object of an authenticated route: res.locals.context.

Let me know if i answered your question, i might have understood it incorrectly.

[Cvmcosta]

@stoosepp The context token is used to retrieve information, not actively call system background functions, through Ltijs you can only call the services specified in the LTI protocol. Unfortunately it can’t be used to call Moodle specific APIs. Depending on what data you want, you can extract it directly from the ID token (res.locals.token on an LTI accessible route), or use one of the LTI services.