LTI XBlock Reusability Bug: Copy/Paste, Libraries, and Cross-Course Import Fail Due to DB-Stored Settings

[usmanpm]

Summary

LTI Consumer (LTI XBlock) has a systemic configuration storage issue that breaks reusability in multiple workflows: copy/paste, use in content libraries, and import/export into different courses. The root cause is that configuration is split between the Studio/module store and a separate database table, and the DB-backed configuration is not kept in sync across these operations.

Affected scenarios

• Duplicating/copy-pasting an LTI XBlock
• Using LTI XBlocks in content libraries
• Importing a course that contains LTI XBlocks into a different course ID

Note: Export + import into the same course ID appears to work, but this is misleading (explained below).

Root cause

Per Feanil’s investigation into the LTI Consumer code:

• The LTI block stores:
  • Some configuration in the normal Studio/module store backend
  • Some configuration in a separate database table created by the block.
• During copy/paste, library usage, and import/export:
  • The Studio/module store data is copied and behaves correctly.
  • The separate DB table entries are not synchronized with these operations.
• As a result, after these operations the block’s Studio-side configuration points to nothing or the wrong thing in the external DB, and the LTI block breaks.

Clarification on import/export behavior

• When a course is exported and re-imported into the same course ID, the LTI block appears to work.
• Reason: the backing DB configuration is keyed by course ID, so re-importing into the same course ID “auto-connects” to the existing DB row.
• When importing into a new course ID, that auto-connection does not exist, and the block is expected to fail.

This explains why export/import can appear to succeed in some tests while the underlying bug still exists.

Proposed direction for a fix

• Move / duplicate problematic settings that live only in the external DB table into the Studio/module store representation of the block.
• There are already some settings that are tracked in both places and kept in sync; the idea is to treat the problematic settings similarly.
• Key questions to validate:
  • What are the implications of moving or duplicating these settings into Studio/module store?
  • What might this change break (e.g., existing deployments, assumptions in other parts of the system, external integrations)?

This area has a lot of externalities, so further testing and validation is required before finalizing the approach.

Value, effort, and timeline

• Fixing this issue would:
  • Enable reliable copy/paste, library usage, and import/export across courses for LTI blocks.
  • Remove the need to recommend the “LTI store” workaround

[navinkarkera]

@feanil @usmanpm I did some testing, and have some doubts.

• The client_id, platform generated private key - public jwk is stored in the database.
• Copying the LTI block and pasting it even in the same course doesn't really work as all the above fields are re-generated for the pasted block and the tool doesn't know these new values.

Now, since I am not very familiar with LTI concepts, I want to clear some doubts:

• Is it expected for the pasted block to work without any changes or without creating a new tool? I thought the client_id is supposed to be unique per block?
• Should we replicate the client_id, and the private - public keys in modulestore?

Let me know if there is more to this and if I am missing the point.

cc: @rpenido @bradenmacdonald

[bradenmacdonald]

@navinkarkera @rpenido

A bit of thought will be required to propose the best solution here.

I thought the client_id is supposed to be unique per block?

Well with "LTI 1.1 Passports" and "LTI Reusable configuration" (1.1 and 1.3), the configuration is definitely shared among multiple blocks, so I think it's fine to share within a course or even for the whole LMS. With the default LTI 1.3 auth workflow, it does seem to be generating a new client ID for each block, but we should be able to override that. Source: https://github.com/openedx/xblock-lti-consumer/blob/master/README.rst

Is it expected for the pasted block to work without any changes or without creating a new tool?

Yes, is my understanding.

Should we replicate the client_id, and the private - public keys in modulestore?

Yes, I think that's the desired outcome here.

But as we mentioned elsewhere, this change will results in secrets being stored in the platform clipboard and/or course export, so "We may also need to update import/export UI messaging to indicate that secrets may be in the export file." and likely the same for "Copy to clipboard" as well.

[navinkarkera]

@bradenmacdonald I have a small rough WIP PR: #603 that replicates these fields in modulestore (whenever the block is opening in studio or a new block is created) and fixes copy-paste by syncing these fields from the block.