WeBWorK Main Forum

LTI 1.3 setup on Moodle

LTI 1.3 setup on Moodle

by Sean Fitzpatrick -
Number of replies: 31

I've just done an upgrade of our production server. Since it'll be mostly idle until September, I've optimistically moved it to the 2.19 branch.

Everything seems to have gone fine, except LTI. Since we now have the option to use LTI 1.3, we decided to try that.

I'm following the instructions here:

https://webwork.maa.org/wiki/LTI_Authentication_(for_WeBWorK_2.18_or_newer)

I sent this to one of our Moodle admins, who followed the Moodle configuration instructions to make a new tool, and sent me the tool configuration details, which I entered in the authen_LTI_1_3.conf file.

In Moodle I tried using the tool to add WeBWorK to a course. I have the Content Selection button, but it only shows the following:



In authen_LTI.conf I uncommented the 'lms_context_id' line for the config variables, but in the LTI tab in course configuration, I only see the grade mode.

What am I missing?

In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -

The fact that you are getting that message in the danger alert with no information below indicates that WeBWorK is finding a course that has the platform id, client id, and deployment id that Moodle is sending.  However, WeBWorK is either not able to decode the JWT or for some reason it does not have the information in the JWT that is expected.

Check that you have all of the $LTI{v1p3} URLs set correctly.  Moodle makes it rather straightforward to find these, so unless you have a typo these are probably correct.

Next, enable $debug_lti_parameters (if you haven't already -- this won't help much at this point though), and enable general WeBWorK debugging by setting "debug: enabled: 1" in the conf/webwork2.mojolicious.yml file (roughly line 223).  Then restart the webwork2 service.

Now inspect the logs/webwork2.log file and logs/debug.log file after you click the content selection button in Moodle.

The general debugging information will be in logs/debug.log.  The logs/debug.log file should show two requests after you click the content selection button in Moodle.  The first should say "The URI is /webwork2/ltiadvantage/login", and the parameters in the request will be shown with other information below.  Then the second should say "The URI is /webwork2/ltiadvantage/launch", and the parameters and other information below.

The information from setting $debug_lti_parameters (if any) will be in logs/webwork2.log. If the JWT is decoded, then its contents will be shown.  If you don't see "JWT PARAMETERS RECEIVED" with the contents below, then the JWT is not being decoded.

In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Glenn Rice -

I forgot to mention that to get the general debugging to go to the debug.log file, you also need to uncomment the line "logfile: /opt/webwork/webwork2/logs/debug.log" that is after the "enabled: 1" line.

In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -

Thanks. I've turned on debugging, but so far, there is no debug.log.

In the webwork2.log file, I see a lot of messages because WeBWorK is trying to do grade passback mass updates for courses from last year, but failing with a message that no LMS user id is available for each user (perhaps because these are old LTI 1.1 courses). I am also seeing "LMS lineitem is not available for the course" on some grade passback attempts.

The last line in webwork2.log, after clicking on the content selection button, is "The LTI Advvantage login route was accessed with the appropriate parameters."

As a check: is it sufficient to set $LTI{v1p3}{preferred_source_of_username} = 'email'; or do I need to uncomment the line below with the same key that includes the LMS URL (which I guess would be something like $LTI{v1p3}{preferred_source_of_username} = 'https://moodle.uleth.ca/mod/lti/claim/ext#email';)?

In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -
Oh, I also have to uncomment the line in the mojolicious yml file that sets the debug log file.
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -
I am getting this sort of thing in the debug log (with client ID redacted):

[Wed Jun 26 10:53:19.342674 2024] (eval):

===> Begin WeBWorK::dispatch() <===

[Wed Jun 26 10:53:19.343540 2024] (eval): Hi, I'm the new dispatcher!
[Wed Jun 26 10:53:19.343666 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 10:53:19.343767 2024] (eval): Okay, I got some basic information:
[Wed Jun 26 10:53:19.343852 2024] (eval): The site location is /webwork2
[Wed Jun 26 10:53:19.343930 2024] (eval): The request method is POST
[Wed Jun 26 10:53:19.344234 2024] (eval): The URI is /webwork2/ltiadvantage/login
[Wed Jun 26 10:53:19.344369 2024] (eval): The argument string is iss=https%3A%2F%2Fmoodle.uleth.ca&target_link_uri=https%3A%2F%2Fwebwork.uleth.ca%2Fwebwork2%2Fltiadvantage%2Fcontent_selection&login_hint=44723&lti_message_hint=%7B%22launchid%22%3A%22ltilaunch_ContentItemSelectionRequest1224621872%22%7D&client_id=(redacted)&lti_deployment_id=208
[Wed Jun 26 10:53:19.344486 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 10:53:19.344675 2024] (eval): The path is /ltiadvantage/login/
[Wed Jun 26 10:53:19.344820 2024] (eval): The current route is ltiadvantage_login
[Wed Jun 26 10:53:19.344914 2024] (eval): Here is some information about this route:
[Wed Jun 26 10:53:19.345004 2024] (eval): The display module for this route is WeBWorK::ContentGenerator::LTIAdvantage
[Wed Jun 26 10:53:19.345081 2024] (eval): This route has the following captures:
[Wed Jun 26 10:53:19.345165 2024] (eval): action => login
[Wed Jun 26 10:53:19.345250 2024] (eval): controller => LTIAdvantage
[Wed Jun 26 10:53:19.345327 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 10:53:19.345401 2024] (eval): Now we want to look at the parameters we got.
[Wed Jun 26 10:53:19.345493 2024] (eval): The raw params:
[Wed Jun 26 10:53:19.345716 2024] (eval): lti_deployment_id => "208"
[Wed Jun 26 10:53:19.345827 2024] (eval): login_hint => "44723"
[Wed Jun 26 10:53:19.345913 2024] (eval): lti_message_hint => "{"launchid":"ltilaunch_ContentItemSelectionRequest1224621872"}"
[Wed Jun 26 10:53:19.346004 2024] (eval): client_id => "(redacted)"
[Wed Jun 26 10:53:19.346095 2024] (eval): target_link_uri => "https://webwork.uleth.ca/webwork2/ltiadvantage/content_selection"
[Wed Jun 26 10:53:19.346180 2024] (eval): iss => "https://moodle.uleth.ca"
[Wed Jun 26 10:53:19.346255 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 10:53:19.372842 2024] (eval): We need to get a course environment (with or without a courseID!)
[Wed Jun 26 10:53:19.379064 2024] (eval): Here's the course environment: WeBWorK::CourseEnvironment=HASH(0x632a23ef2960)
[Wed Jun 26 10:53:19.426841 2024] (eval): Using user_authen_module WeBWorK::Authen::LTIAdvantage: WeBWorK::Authen::LTIAdvantage=HASH(0x632a23f65608)
[Wed Jun 26 10:53:19.427037 2024] (eval): We got a courseID from the route, now we can do some stuff:
[Wed Jun 26 10:53:19.427147 2024] (eval): ...we can create a database object...
[Wed Jun 26 10:53:19.467021 2024] (eval): (here's the DB handle: WeBWorK::DB=HASH(0x632a1e65fac8))
[Wed Jun 26 10:53:19.467598 2024] WeBWorK::Authen::LTIAdvantage::verify: The LTI Advantage login route was accessed with the appropriate parameters.
[Wed Jun 26 10:53:19.614973 2024] (eval):
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -
OK, so I am not seeing the "JWT PARAMETERS RECEIVED" message anywhere. Is that a sign of a configuration error on the Moodle end, or my end?

I'm a bit curious what I should see when it works. E.g. how do I ensure that a particular Moodle course gets associated to the correct WeBWorK course?
With 1.1 our faculty know to just paste in the URL for their WeBWorK course, and Moodle configures the rest. I might choose to avoid 1.3 if it means a lot of extra faculty support.

Other updates: the debug log just logged an instance of somebody trying to log into a Physics course from Spring 2023 that I've archived and deleted. Weird. I guess they clicked on an old LTI link? (Why a student would be trying to use a WW link that's over a year old, I don't know...)

Also: I have the preferred source of user ID set to email, but it looks like the only thing coming through with LTI 1.3 is a "Moodle ID". (This is the number in the login hint.) We have a weird rule where student numbers aren't exposed in the LMS, due to privacy reasons or some such thing, so there is a separate Moodle ID that is created.
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -
The email address is only in the decoded JWT. So until you get to that you won't see the email address.
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -

There should be another request to the /ltiadvantage/launch route that comes after the request to the /ltiadvantage/login route.  I don't know how you could get the screen shot that you showed without the second request occurring.

Yes, you want $LTI{v1p3}{preferred_source_of_username} = 'email';.  The email address is in the "email" key of the decoded JWT.  There are other claims that include the purl in the key name like the example commented out below.

In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -

You're right. If I start with a clean log, I get two blocks. There are some very long id_token strings that I'm going to truncate for readability in the second block.

[Wed Jun 26 11:39:40.576696 2024] (eval): 

===> Begin WeBWorK::dispatch() <===

[Wed Jun 26 11:39:40.577039 2024] (eval): Hi, I'm the new dispatcher!
[Wed Jun 26 11:39:40.577165 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 11:39:40.577250 2024] (eval): Okay, I got some basic information:
[Wed Jun 26 11:39:40.577329 2024] (eval): The site location is /webwork2
[Wed Jun 26 11:39:40.577405 2024] (eval): The request method is POST
[Wed Jun 26 11:39:40.577579 2024] (eval): The URI is /webwork2/ltiadvantage/login[Wed Jun 26 11:39:40.577675 2024] (eval): The argument string is iss=https%3A%2F%2Fmoodle.uleth.ca&target_link_uri=https%3A%2F%2Fwebwork.uleth.ca%2Fwebwork2%2Fltiadvantage%2Fcontent_selection&login_hint=44723&lti_message_hint=%7B%22launchid%22%3A%22ltilaunch_ContentItemSelectionRequest1912013487%22%7D&client_id=(redacted)&lti_deployment_id=208
[Wed Jun 26 11:39:40.577753 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 11:39:40.577881 2024] (eval): The path is /ltiadvantage/login/
[Wed Jun 26 11:39:40.578000 2024] (eval): The current route is ltiadvantage_login
[Wed Jun 26 11:39:40.578082 2024] (eval): Here is some information about this route:
[Wed Jun 26 11:39:40.578165 2024] (eval): The display module for this route is WeBWorK::ContentGenerator::LTIAdvantage
[Wed Jun 26 11:39:40.578240 2024] (eval): This route has the following captures:
[Wed Jun 26 11:39:40.578317 2024] (eval): controller => LTIAdvantage
[Wed Jun 26 11:39:40.578398 2024] (eval): action => login
[Wed Jun 26 11:39:40.578491 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 11:39:40.578568 2024] (eval): Now we want to look at the parameters we got.
[Wed Jun 26 11:39:40.578641 2024] (eval): The raw params:
[Wed Jun 26 11:39:40.578808 2024] (eval): lti_deployment_id => "208"
[Wed Jun 26 11:39:40.578901 2024] (eval): login_hint => "44723"
[Wed Jun 26 11:39:40.578996 2024] (eval): client_id => "(redacted)"
[Wed Jun 26 11:39:40.579095 2024] (eval): lti_message_hint => "{"launchid":"ltilaunch_ContentItemSelectionRequest1912013487"}"
[Wed Jun 26 11:39:40.579178 2024] (eval): target_link_uri => "https://webwork.uleth.ca/webwork2/ltiadvantage/content_selection"
[Wed Jun 26 11:39:40.579258 2024] (eval): iss => "https://moodle.uleth.ca"
[Wed Jun 26 11:39:40.579334 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 11:39:40.597463 2024] (eval): We need to get a course environment (with or without a courseID!)
[Wed Jun 26 11:39:40.603650 2024] (eval): Here's the course environment: WeBWorK::CourseEnvironment=HASH(0x632a24d699f0)
[Wed Jun 26 11:39:40.604128 2024] (eval): Using user_authen_module WeBWorK::Authen::LTIAdvantage: WeBWorK::Authen::LTIAdvantage=HASH(0x632a24d6df98)
[Wed Jun 26 11:39:40.604264 2024] (eval): We got a courseID from the route, now we can do some stuff:
[Wed Jun 26 11:39:40.604364 2024] (eval): ...we can create a database object...
[Wed Jun 26 11:39:40.616717 2024] (eval): (here's the DB handle: WeBWorK::DB=HASH(0x632a24d68f88))
[Wed Jun 26 11:39:40.617190 2024] WeBWorK::Authen::LTIAdvantage::verify: The LTI Advantage login route was accessed with the appropriate parameters.
[Wed Jun 26 11:39:40.735927 2024] (eval): 

===> Begin WeBWorK::dispatch() <===

[Wed Jun 26 11:39:40.736060 2024] (eval): Hi, I'm the new dispatcher!
[Wed Jun 26 11:39:40.736152 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 11:39:40.736241 2024] (eval): Okay, I got some basic information:
[Wed Jun 26 11:39:40.736321 2024] (eval): The site location is /webwork2
[Wed Jun 26 11:39:40.736396 2024] (eval): The request method is POST
[Wed Jun 26 11:39:40.736546 2024] (eval): The URI is /webwork2/ltiadvantage/launch
[Wed Jun 26 11:39:40.736634 2024] (eval): The argument string is id_token=eyJ0eXAiOiJKV1QiLCJhb(truncated)
[Wed Jun 26 11:39:40.736767 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 11:39:40.736888 2024] (eval): The path is /ltiadvantage/launch/
[Wed Jun 26 11:39:40.736987 2024] (eval): The current route is ltiadvantage_launch
[Wed Jun 26 11:39:40.737064 2024] (eval): Here is some information about this route:
[Wed Jun 26 11:39:40.737146 2024] (eval): The display module for this route is WeBWorK::ContentGenerator::LTIAdvantage
[Wed Jun 26 11:39:40.737220 2024] (eval): This route has the following captures:
[Wed Jun 26 11:39:40.737296 2024] (eval): action => launch
[Wed Jun 26 11:39:40.737370 2024] (eval): controller => LTIAdvantage
[Wed Jun 26 11:39:40.737459 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 11:39:40.737548 2024] (eval): Now we want to look at the parameters we got.
[Wed Jun 26 11:39:40.737623 2024] (eval): The raw params:
[Wed Jun 26 11:39:40.737761 2024] (eval): id_token => "eyJ0eXAiOiJKV1QiLCJhbGciOiJSU(truncated)"
[Wed Jun 26 11:39:40.737920 2024] (eval): state => "44110d853c7108da11772b32586fe604b6fe95796532e576a9e70de1fc3d1b5a"
[Wed Jun 26 11:39:40.738002 2024] (eval): --------------------------------------------------------------------------------
[Wed Jun 26 11:39:40.929027 2024] (eval): We need to get a course environment (with or without a courseID!)
[Wed Jun 26 11:39:40.935228 2024] (eval): Here's the course environment: WeBWorK::CourseEnvironment=HASH(0x632a24b4e558)
[Wed Jun 26 11:39:40.935750 2024] (eval): Using user_authen_module WeBWorK::Authen::LTIAdvantage: WeBWorK::Authen::LTIAdvantage=HASH(0x632a24fcc3b8)


In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -
Can you check something in your database? What do you see if you enter "select * from courseID_setting;"? Do you see an entry with the name "LTIAdvantageLMSPublicKey"?  Of course, change "courseID" to the name of the course you are actually using.
In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -
Dumb question, but what should I use for the course ID. We use a naming scheme like "Math-1560-Fall-2023" for courses on WeBWorK. The hyphens seem to cause a SQL syntax problem. (Database syntax is not my strong point. I tried "SELECT * FROM Math-1560-Fall-2023_setting;")
If you mean the Moodle ID, I don't have access to that database.

Possibly relevant: we did a clean OS install to upgrade, as we had previously encountered some bugs trying to upgrade a VM from Ubuntu 20.04.

So our upgrade steps were:
- database dump and save a copy of /opt/webwork/courses
- install Ubuntu 24.04 and WeBWorK 2.19 from scratch
- restore the courses folder and import the database
- use the admin course to upgrade databases

I don't have any new courses created yet. Everything on our server would have used LTI 1.1 on WeBWorK 2.17.
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -
Oh, now I see that in the admin course, there's an area called "Manage LTI Course Map". The LMS Context ID field is blank for all the courses. I guess this is something I also need to set for each course.

Ahh, but first I need to get the context ID from the external tool in the LMS.

Does this mean that to set up a course using LTI 1.3, I have to:

- Get a request from the instructor, make the course on WeBWorK
- Have them set up an external tool, and get the red warning message, but it comes with the data about the context ID
- Get them to send me the context ID
- Set the context ID for their course from the admin course
- Let them know they can now go activate their external tool?

Right now I just give them the URL to their course on WeBWorK and they paste it into the external tool.
I'm not sure everyone will cope if I tell them there are extra steps.
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -
You can still do that. Just create the course in WeBWorK. If you also give them an initial password (that they presumably would change to something more secure), then enable the LTI course configuration tab by uncommenting the elements of the @LTIConfigVariables array in authen_LTI.conf. Then the instructors can set the context id themself.
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -
I did mean the WeBWorK database. I use hyphens in my course ids as well. That means that you need to use backticks around the course id for the database query. So use "SELECT * FROM `Math-1560-Fall-2023_setting`;". I should have just included the backticks when I first gave the command since they always work.

Are you saying there are no courses on your webwork server (other than the admin course which I assume you have)? If that is the case, then the content selection end point certainly won't work, and that would be the reason that you got the screen shot you gave. There has to be at least one course that is set up to use LTI 1.3 in order for the end point to work.
In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -
Sorry, I was unclear. There are lots of courses on the webwork server, but they were all copied over from the previous version, which was running WeBWorK 2.17 on Ubuntu 20.04. Now we're on 2.19 with Ubuntu 24.04. I imported the old database and upgraded it.

But I wasn't sure if courses created on older versions of WeBWorK would be set up to use LTI 1.3.

In the database for one of my courses from last year, I see the LTIAdvantageLMSPublicKey, with several entries in it ("kty", "alg", "kid", "e", "n", and "use").

I created one new test course to see if anything looked different, but I didn't notice anything.
In the course configuruation page, I have an LTI tab, but only the grade mode option is there. In authen_LTI.conf I have:

@LTIConfigVariables = (
        #'LTI{v1p1}{LMS_name}',
        #'LTI{v1p3}{LMS_name}',
        #'LTI{v1p1}{LMS_url}',
        #'LTI{v1p3}{LMS_url}',
        #'external_auth',
        'LTIGradeMode',
        #'LMSManageUserData',
        #'debug_lti_parameters',
        'lms_context_id'
);

so there should be something for the context id.

Is there anything in the new course creation that requires me to copy templates from the model course for LTI to work?
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -
Does the course from last year have $LTIVersion = 'v1p3'; in its course.conf file? In other words, is it set up for LTI 1.3? Is that the course that you are testing LTI 1.3 with?  Or do you have $LTIVersion = 'v1p3'; in authen_LTI.conf?  If that is the case, then all courses will now be using LTI 1.3.

You should see the context id setting in the course configuration tab if it is uncommented. Did you restart hypnotoad after you made that change?
In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -
I set the LTIVersion to v1p3 globally. I can try also putting it directly in the course.conf file. And yes, I have restarted the server several times.
What should I be seeing on the Moodle side? Initially, the warning page, but it contains the context id, which then needs to be set?

Some old courses would have an lti grade mode setting in course.conf, since our default mode is 'course' but some of us (like me) prefer 'homework'.

OH! I see the context id field if I sign in as admin, but not if I sign in as an instructor.
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -
I forgot one thing. All of the course configuration variables now have an associated permission. By default none of them are set (which means any user with the modify_problem_sets permission can change them). That is except for the "change_config_lms_context_id" permission which is set to admin. So you will need to set that in localOverrides.conf. Add "$permissionLevels{change_config_lms_context_id} = 'professor';" to localOverrides.conf to make the setting available for those with the professor role.

Initially, an instructor that attempts to use content selection will see the screen shot you showed, except if everything is configured correctly it will show the LMS context id for the course below.  Then the instructor can sign into the webwork course using a username and password, and set the context id on the config page (or have an admin user do it in the admin course if that is not allowed).

If all of your courses (or at least the majority of them) are going to use LTI 1.3, then you should enable it globally.  Any course that will use a different LTI setup than the global configuration needs to have the settings set in the course.conf file.
In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -

Thanks for your help Glenn, but I am at a loss. I've been through the LTI instructions and the config files several times, and I can't find anything wrong. Is there anything that could have been done wrong on the LMS side to cause the problem? I'll check with our Moodle people later today.

But right now all signs are pointing toward reverting to LTI 1.1.

In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -
If you could meet over Zoom, perhaps we could get it figured out. Would you be able to do that?
In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -

Yes, thanks. That would work. Today I have a meeting at 2 pm (I'm on Mountain Time -- that's 25 minutes from now) but I could meet at 3 pm, or some time tomorrow -- possibly the PreTeXt drop-in tomorrow afternoon?

In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -

Either works for me. Just let me know.

In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -
OK, let's talk at 3 pm -- that's 45 minutes from now (I forget your time zone!)
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -
Update: I went through and cleaned the database, and I also set all of our old courses to use LTI 1.1.
I'm still not getting context information on the Moodle side.

We're wondering if it might be because our Moodle setup involves several instances running on a load balancer.

Even the course that worked yesterday won't work today, although I didn't save an external tool yesterday
In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -

OK, it seems that the trick is to leave things set to use LTI 1.1. globally, and then enable 1.3 on a per-course basis.

Possibly I can put the 1.3 configuration in the course.conf for the model course, and then copy templates from there for new courses.

In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Glenn Rice -
I don't think that setting it on a per-course basis will help any. Once you have several courses set to use LTI 1.3, then I think you will still have the same issue.

I think that there may be an issue with having several Moodle instances running behind a load balancer if not configured correctly. Is it possible that each instance has its own public key? If that is the case, it would certainly be a problem. The different Moodle instances would need to be configured to use a shared public key. I don't know how to configure several instances behind a load balancer for that though. If each instance has its own key, then on successive requests (most importantly on a login and then launch request) you have the wrong information from a different Moodle instance which won't work for the next Moodle instance.
In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -

Ok. That's information I can take to our Moodle people next week, and we'll see what we can do.

It's not the first time we've had LTI trouble because of our setup. (I recall having all sorts of trouble getting Crowdmark to work; they're using LTI 2.0,I think )

In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -

Follow-up: we couldn't get LTI 1.3 to work, nor could we get the 'deep linking' for LTI 1.1 to work.

So we went back to the old setup, of using the URL to configure the external tool.

In reply to Sean Fitzpatrick

Re: LTI 1.3 setup on Moodle

by Andrew Ruether -

We were able to get LTI 1.1 deep linking working in Moodle on WW 2.19 by doing the following:

Adding the $authen{user_module} settings to localOverrides.conf

$authen{user_module} = [
        { '*' => 'WeBWorK::Authen::LTIAdvantage' },        # LTI 1.3
        { '*' => 'WeBWorK::Authen::LTIAdvanced' },          # LTI 1.1
        { '*' => 'WeBWorK::Authen::Basic_TheLastOption' }    # fallback authorization method
];

I believe there is a typo in Moodle LTI 1.1 instructions, under Deep linking

Is: https://webwork.yourschool.edu/webwork2/ltiadvantage/content_selection
Should be: https://webwork.yourschool.edu/webwork2/ltiadvanced/content_selection

I had problems with cookies to keep track of sessions. We also use CAS for authentication, so maybe that is causing cookie problems. Switching to key made it work. In localOverrides.conf:

$session_management_via = "key";

Moodle sends over the email to use as the WW username. We needed to make sure the professor is added to the WW course with the email as the username in order to allow them to select content.

Hope that helps,

- Andrew



In reply to Andrew Ruether

Re: LTI 1.3 setup on Moodle

by Glenn Rice -

Yes, that should be https://webwork.yourschool.edu/webwork/ltiadvanced/content_selection in the LTI 1.1 instructions.  The ltiadvantage url is for LTI 1.3.

You shouldn't set $authen{user_module} in localOverrides.conf. That should be set in authen_LTI.conf. That is unless you are using another remote authentication method (like LDAP).

We need to add to the instructions about cookies.  In order to use the content selection endpoints with either version of LTI, you need to enable cross-site tracking (or allow third-party cookies depending on what your browser calls this setting).  Otherwise cookies will not be set when the content selection dialog is rendered in an iframe by the LMS.

I don't recommend using $session_management_via = "key".  That is not very secure.

In reply to Glenn Rice

Re: LTI 1.3 setup on Moodle

by Sean Fitzpatrick -

Sorry for the long delay following up. Summer happened.

I didn't try doing session management via key, since the config files are full of warnings not to do it.

We decided to stick with the old method of using a URL to configure each tool. If a later version of Moodle stops supporting this, I will have to hope IT is willing to configure the load balancer to work. (I suspect they will have to, as WeBWorK is not the only LTI tool we use.)