search

Cvmcosta / ltijs

Turn your application into a fully integratable LTI 1.3 tool provider.
https://cvmcosta.github.io/ltijs/
Apache License 2.0
299 stars 67 forks source link

Can we also get the original JSON payload (in locals) when receiving a launch request? #154

Closed dmolin closed 2 years ago

dmolin commented 2 years ago

Is your feature request related to a problem? Please describe. With the current implementation, when we receive a launch request (in lti.onConnect()) we get the "token" parameter (also in res.locals.token) that represents an "ltijs" human-readable version of the original LTI JSON payload decoded from the JWT. It would be useful to also get the original payload. This is specially important when integrating ltijs with pre-existing code that already deals/work with the expected LTI1.3 JSON Payload structure.

Describe the solution you'd like Having the original JSON payload (the "valid" variable as in line 242 in Provider.js) stored in locals.payload (or any other meaningful variable name) so we can always access the "original" payload along with the "flavoured" one returned by LTIjs. Alternatively (but requiring more work on your side), an optional boolean parameter passed to setup() could be used to tell LTIjs if we want this "translation" to occur in the first place.

Describe alternatives you've considered Right now the only course of action I'm taking is to write a function on my side that "rebuild" the original LTIjs payload from the one returned by LTIjs. Not ideal but it's the only way to then pipe this code into my current codebase where we already process and work with the standard LTI JSON structure.

dmolin commented 2 years ago

Nevermind. This has more ramifications than I thought and I can manage working with the ltijs JSON payload anyway.