LTI User mapping doesn't work since 4.4
Steps to reproduce
Steps to reproduce:
1. Configure Opencast as an LTI tool provider.
2. Remove the fourth constructor argument from the LtiLaunchAuthenticationHandler in etc/security/mh_default_org.xml.
3. Send an LTI request with "ext_user_username" set to the name of an existing Opencast user.
Actual Results:
You are not authenticated as that user.
Expected Results:
You should be authenticated as that user.
Workaround (if any):
Add a fourth constructor argument, e.g. like this: https://github.com/opencast/opencast/commit/ef7bc8e94936b426bec5cb52f846d81c8c903657
Activity
Issue is fixed. I attached a patch.
P.S.: I noticed this also affects 3.6, but I can't edit the issue description anymore.
I don't know if it's even necessary to test this. You should be able to see what's wrong by just looking at the change that introduced this bug: https://github.com/opencast/opencast/commit/ef7bc8e94936b426bec5cb52f846d81c8c903657#diff-b59bf6d5547016d01917d80f5357b9feR118
@timschroeder, my assumption is that the reason the 3 parameter method was made impotent was to prevent the admin-to-admin vulnerability. If this was infact the case, that 3 param method should have been removed altogether to force the 4 param call.
Your pull allows sites to streamline by ignoring the vulnerability by avoiding the 4th param with the exception cases. The aternative would have been to force adopters to send an empty set in the 4th param (via that updated etc/security/mh_default_org.xml) to manually permit admin-to-admin super powers between systems.
@Karen Dolan: I see. I agree that if that's the case, the 3 parameter constructor should be removed entirely. I made a new Issue MH-13082 for it. I’ll make a pull request for it as well.
