feat: LTI 1.3 Passport Refactor + Database Cleanup Support by navinkarkera · Pull Request #627 · openedx/xblock-lti-consumer

navinkarkera · 2026-03-19T14:32:38Z

Description

Split LTI 1.3 Configuration into Passport Model

Introduce Lti1p3Passport model to centralize LTI 1.3 keys and credentials
Move lti_1p3_internal_private_key, lti_1p3_internal_private_key_id, lti_1p3_internal_public_jwk, lti_1p3_client_id, lti_1p3_tool_public_key, and lti_1p3_tool_keyset_url fields from LtiConfiguration to Lti1p3Passport
Add ForeignKey relationship from LtiConfiguration to Lti1p3Passport
Implement passport-based key generation and retrieval
Add clean() validation to Lti1p3Passport to ensure at least one of lti_1p3_tool_public_key or lti_1p3_tool_keyset_url is set
Update validation in LtiConfiguration.clean() to check for passport presence instead of tool key fields
Refactor get_or_create_local_lti_config() to handle passport creation and sync block/passport key configurations
Update API endpoints to work with passport ID instead of configuration ID
Add admin interface for Lti1p3Passport model
Refactor access_token_endpoint and public_keyset_endpoint to use passport ID
Update API and views to work with the new passport model
Generate migration to remove fields from LtiConfiguration table
Update data migration to copy existing configurations to the new Passport model
Update XBlock to store passport ID instead of config ID
Fix copy-paste issue in resource_link_id generation

Support Database Cleanup for Deleted Blocks

New signal handlers to:
- Automatically delete orphaned configurations during pre_item_delete (block/children).
- Purge unused passport objects from the LTI 1.3 Passport model.

Test instructions

Use sandbox to test.
Create a working 1.3 LTI xblock.
Copy and paste the xblock.
Make sure both xblocks are working.
Go to <studio_url>/admin/lti_consumer/ and check configuration and passport entries.
Both configuration should use a single passport.
Now go and modify lti_1p3_tool_keyset_url in one of the xblocks and save. This should create a new passport entry instead of modifying the original one to avoid changing other block.
Finally test all LTI 1.3 features to make sure that we have not broken existing features.

openedx-webhooks · 2026-03-19T14:32:45Z

Thanks for the pull request, @navinkarkera!

This repository is currently maintained by @Faraz32123.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
- This process (including the steps you'll need to take) is documented here.
If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

Dependencies

This PR must be merged before / after / at the same time as ...
Blockers

This PR is waiting for OEP-1234 to be accepted.
Timeline information

This PR must be merged by XX date because ...
Partner information

This is for a course on edx.org.
Supporting documentation
Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

🔘 Update the status of your PR

Your PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate.

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

The size and impact of the changes that it introduces
The need for product review
Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

- Introduce Lti1p3Passport model to centralize LTI 1.3 keys and credentials - Move lti_1p3_internal_private_key, lti_1p3_internal_private_key_id, lti_1p3_internal_public_jwk, lti_1p3_client_id, lti_1p3_tool_public_key, and lti_1p3_tool_keyset_url fields from LtiConfiguration to Lti1p3Passport - Add ForeignKey relationship from LtiConfiguration to Lti1p3Passport - Implement passport-based key generation and retrieval - Add clean() validation to Lti1p3Passport to ensure at least one of lti_1p3_tool_public_key or lti_1p3_tool_keyset_url is set - Update validation in LtiConfiguration.clean() to check for passport presence instead of tool key fields - Refactor get_or_create_local_lti_config() to handle passport creation and sync block/passport key configurations - Update API endpoints to work with passport ID instead of configuration ID - Add admin interface for Lti1p3Passport model - Refactor access_token_endpoint and public_keyset_endpoint to use passport ID - Update API and views to work with the new passport model - Generate migration to remove fields from LtiConfiguration table - Update data migration to copy existing configurations to the new Passport model - Update XBlock to store passport ID instead of config ID - Fix copy-paste issue in resource_link_id generation

* Add signal handlers to delete LTI configurations when xblocks or library blocks are deleted * Ensure LTI configurations are properly cleaned up when associated blocks are removed from the system * Update documentation for LTI 1.3 configuration changes to inform users about potential regeneration of client IDs and URLs when public keys are changed

• Fixed spelling errors (configurtion → configuration, url → URL) • Improved log messages to be more informative • Used more descriptive variable names (id_list → block_locations) • Maintained consistent code style and import organization

navinkarkera · 2026-03-20T06:35:54Z

@ayub02 Please use the sandbox to test.

codecov · 2026-03-20T13:10:03Z

Codecov Report

❌ Patch coverage is 97.26316% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 98.22%. Comparing base (17830a1) to head (9cc408d).

Files with missing lines	Patch %	Lines
lti_consumer/api.py	77.27%	5 Missing ⚠️
lti_consumer/admin.py	80.00%	3 Missing ⚠️
lti_consumer/models.py	96.62%	3 Missing ⚠️
lti_consumer/plugin/views.py	91.66%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #627      +/-   ##
==========================================
+ Coverage   97.59%   98.22%   +0.62%     
==========================================
  Files          79       59      -20     
  Lines        6871     6942      +71     
==========================================
+ Hits         6706     6819     +113     
+ Misses        165      123      -42

Flag	Coverage Δ
unittests	`98.22% <97.26%> (+0.62%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

feanil

@navinkarkera I like the approach of adding a new model for storing lti credentials independent of the blocks, this would obviate the need for external storage and make it easier to re-use storage. I've got a few questions specific to the implementation but I think this is the idea that we should try to land.

@ayub02 a question for you: Should import/export work for LTI blocks from one open edx instance to another? This has not worked before but this change will not really fix that either.

feanil · 2026-03-23T14:10:44Z

lti_consumer/plugin/compat.py

+    """
+    Load enough of an xblock to read from for LTI values stored on the block.
+    The block may or may not be bound to the user for actual use depending on
+    what has happened in the request so far.
+    """


TODO: Update this docstring.

feanil · 2026-03-23T14:28:43Z

lti_consumer/models.py

                    f'Failed to parse main LTI configuration location: {self.location}',
                )

+    def create_lti_1p3_passport(self):


This is a get or create in practice right? So let's update the name.

feanil · 2026-03-23T14:29:58Z

lti_consumer/utils.py

        # Remove private and excluded fields.
        for key in list(object_fields):
-            if key.startswith('_') or key in exclude:
+            if key.startswith('_') or key in exclude or (include and key not in include):


What's the reason for this?

Just to allow us to include some fields instead of excluding lot of fields incase we only need few of them.

feanil · 2026-03-23T14:37:40Z

lti_consumer/models.py

+    """
+    Model to store LTI 1.3 keys.
+    """
+    passport_id = models.UUIDField(unique=True, default=uuid.uuid4, editable=False)


Does it make sense to add a passport_name field now and let the users set it so that when we make this re-usable they will already have human readable names and we can show them to the user? Also currently these settings have no scope. Since we're newly introducing it, does it make sense to make it scoped to a context key of some sort to begin with?

Does it make sense to add a passport_name field now

Yes, good idea!

Since we're newly introducing it, does it make sense to make it scoped to a context key of some sort to begin with?

Makes sense. Should we worry about them being used out of context for now? Like if you copy and paste in different courses, they will be using the same passport.

About passport_name:

Should we make this field unique in combination with the context_key?

We'll still need passport_id as it needs to be unique across the table.

feanil · 2026-03-23T14:45:42Z

lti_consumer/migrations/0022_remove_lticonfiguration_lti_1p3_client_id_and_more.py

Should we also be dropping these fields from the xblock at the same time? We're not really using them for storage as much as to make it easier to use the old studio block rendering helper. Since we're redoing the frontend, do we need those fields to exist on the block? @rpenido perhaps you're the right person to answer that question?

We are moving them (including existing data) to passport model.

AFAIK, the frontend doesn't really depend on the database models.

feanil · 2026-03-23T14:50:45Z

lti_consumer/migrations/0021_create_lti_1p3_passport.py

+    for configuration in LtiConfiguration.objects.all():
+        try:
+            block = load_enough_xblock(configuration.location)
+            block.lti_1p3_passport_id = str(configuration.config_id)


Shouldn't this be the lti_1p3_passport.id ? Should we also need to add a field for the LtiConfiguration to the block?

We use config_id as passport_id in migration as we want the existing blocks to work without requiring any change in the LTI tool configuration. After this PR, passport_id is included in the access_token and keyset urls instead of config_id.

openedx-webhooks added open-source-contribution PR author is not from Axim or 2U core contributor PR author is a Core Contributor (who may or may not have write access to this repo). labels Mar 19, 2026

openedx-webhooks added this to Contributions Mar 19, 2026

github-project-automation bot moved this to Needs Triage in Contributions Mar 19, 2026

navinkarkera mentioned this pull request Mar 19, 2026

feat: decouple xblock and lti config to fix copy-paste #606

Draft

7 tasks

navinkarkera added 3 commits March 19, 2026 20:04

navinkarkera requested review from Faraz32123, feanil and rpenido March 19, 2026 14:38

fix: lint issues

45ce7ac

navinkarkera force-pushed the navin/fal-4318/split-config branch from c391f5e to 45ce7ac Compare March 19, 2026 14:49

feat: install openedx-events

2280f94

navinkarkera mentioned this pull request Mar 19, 2026

feat: add pre-item-delete signal openedx/openedx-platform#38192

Draft

navinkarkera added 2 commits March 19, 2026 20:57

fix: model label

4f1be85

fix: handle no location

d1560d3

navinkarkera added 2 commits March 20, 2026 18:11

test: fix tests

bbed967

fix: lint issues

7becfcb

navinkarkera force-pushed the navin/fal-4318/split-config branch from 08ac0d2 to 7becfcb Compare March 20, 2026 12:41

fixup! fix: lint issues

f28c502

test: add signal tests

b7c06db

navinkarkera force-pushed the navin/fal-4318/split-config branch from 1369128 to b7c06db Compare March 22, 2026 15:05

fix: coverage

9cc408d

feanil reviewed Mar 23, 2026

View reviewed changes

mphilbrick211 added the FC Relates to an Axim Funded Contribution project label Mar 23, 2026

mphilbrick211 moved this from Needs Triage to Waiting on Author in Contributions Mar 23, 2026

Conversation

navinkarkera commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Split LTI 1.3 Configuration into Passport Model

Support Database Cleanup for Deleted Blocks

Related

Test instructions

Uh oh!

openedx-webhooks commented Mar 19, 2026

Uh oh!

navinkarkera commented Mar 20, 2026

Uh oh!

codecov bot commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

feanil left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

navinkarkera Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

navinkarkera commented Mar 19, 2026 •

edited

Loading

codecov bot commented Mar 20, 2026 •

edited

Loading

navinkarkera Mar 24, 2026 •

edited

Loading