Closed dmolin closed 5 months ago
When using the servless options, LTIJS defaults to the requester baseUrl and its "/" context when redirecting back to our application.
This PR makes it possible to specify a custom context that will be used by the Express server when dealing with LTIjs messaging.
Example usage:
provider = Provider.setup( ltiSignKey, { url: ltiDB }, { // options tokenMaxAge: 60 * 60, // 1 hour appRoute: "/launch", loginRoute: "/login", cookies, dynRegRoute: "/register", dynReg: { url: `${settings?.public?.baseUrl}/ltitool`, name: `${settings?.private?.lti?.toolName || "LTI Tool"}`, description: `${settings?.private?.lti?.toolDesc || "LTI Tool Description"}`, redirectUris: [], autoActivate: true } }, log ); // deploy the LTI provider in serverless mode and bind it to the context '/ltitool' await Provider.deploy({ serverless: true, path: "/ltitool" });
This will result in "/ltitool/launch", "/ltitool/login", "/ltitool/register" to be used by the Express server as intended.
closing this, since I'm moving my local repository to a new account. will re-open shortly from the new github account.
When using the servless options, LTIJS defaults to the requester baseUrl and its "/" context when redirecting back to our application.
This PR makes it possible to specify a custom context that will be used by the Express server when dealing with LTIjs messaging.
Example usage:
This will result in "/ltitool/launch", "/ltitool/login", "/ltitool/register" to be used by the Express server as intended.