Fix LTI auth_mode inconsistency between user creation and UI #11066
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
User creation uses ext_consumer_id but UI used consumer_pk, causing orphaned auth_modes when providers are deleted. - getAuthModes(): Use ext_consumer_id instead of consumer_pk - lookupConsumer(): Look up in lti_ext_consumer table directly
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fixes LTI auth_mode design inconsistency where user creation and UI use different database fields, causing orphaned
auth_modes and incorrect provider labels.
Mantis: https://mantis.ilias.de/view.php?id=47138
Problem
The codebase has inconsistent interpretation of what auth_mode represents:
User creation: uses ext_consumer_id (global provider)
UI dropdown: uses consumer_pk (course-level connection ID)
When admins delete a global LTI provider, course connections are removed (creating gaps in consumer_pk sequence), but remaining connections still assign auth_modes based on ext_consumer_id. This causes:
Users with auth_modes not in dropdown
Incorrect provider labels (shows wrong provider name)
Saving affected users corrupts their auth_mode → breaks LTI login
Solution
Make the code consistent by using ext_consumer_id throughout:
getAuthModes(): Query ext_consumer_id instead of consumer_pk
lookupConsumer(): Look up provider in lti_ext_consumer table directly
This aligns auth_mode with its semantic meaning: "which provider authenticates this user" (analogous to auth_mode=ldap),
not "which course-connection was used".
Changes
getAuthModes(): Changed query to use ext_consumer_id
lookupConsumer(): Look up directly in lti_ext_consumer table instead of through ilLTIPlatform::fromRecordId()
Testing
Tested with reproduction scenario from mantis ticket. Users created via LTI now have auth_modes that correctly appear in
dropdown, even after provider deletion.
Backward Compatibility
Safe for existing users: user creation always used ext_consumer_id, so all existing users already have correct auth_mode
values. Only users previously corrupted by manual edits are affected (already broken).