Whitelist LTI parameters in site admin

Bug #1785542 reported by shane nuessler
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mahara
Won't Fix
Wishlist
Unassigned

Bug Description

Hi Team,
At UC we are using:
Mahara 17.10
LMS is Canvas

We are trying to configure LTI, which we can do, however the LTI connection from Mahara to Canvas fails because Canvas is passing the SSID (Course ID) which Mahara doesn't care about and so dumps the connection attempt. I have attached a screen shot on an email as it keeps all the elements of the email together which has screenshots and text which is not a combination supported by this bug submission text editor.
Cheers,
Shane.

Tags: lti
Revision history for this message
shane nuessler (edunutter) wrote :
Revision history for this message
Kristina Hoeppner (kris-hoeppner) wrote : Re: LTI: Additional Canvas parameter is not ignored

Hi Shane. Can you please provide information on your setup for the user account? Where would the SSID be set on the user account?

summary: - mahara lti
+ LTI: Additional Canvas parameter is not ignored
Revision history for this message
Kristina Hoeppner (kris-hoeppner) wrote :

I've received some more information via email.

Shane's colleague did a quick lookup on IMS global LTI tool compare: https://www.imsglobal.org/toolcompare.html

It looks like the parameter in question (lis_course_offering_sourcedid) is not defined in Mahara LTI Optional Params list.

I had a dig through the code because I knew that we had written code that would ignore certain parameters that Mahara doesn't know / need to know that Canvas was sending through. It turns out that it was parameters prefixed with "custom", which is not the case here. Thus, an exception is thrown as expected because it does need to be dealt with.

It would be worthwhile checking again if we can / should cast the net wider so as not only to ignore "custom" but others as well that could come through and let admins know when the site is not in production mode as was done at https://git.mahara.org/mahara/mahara/commit/e120d8fd2a6c20b8ae510d1e16deb113dbd6f85d so they can decide whether further action needs to be taken or if the parameter can be ignored without any issue.

Changed in mahara:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Kristina Hoeppner (kris-hoeppner) wrote :

Rather than adding more exceptions into the core code like we did at https://git.mahara.org/mahara/mahara/commit/f7db1828c392eb23829e21e683e894092025dc2b because that could become a very long list.

Revision history for this message
Robert Lyon (robertl-9) wrote :

What would be useful is be able to set/amend the optional launch_parameters() array via an admin interface and save them/fetch them via database as a way to extend the current hard-coded set.

That way a Mahara site can adjust their integration as needed depending on what options are in the LTI source being sent.

Revision history for this message
shane nuessler (edunutter) wrote :

Thank you Kristina, Rob,
Wangchen (my colleague who is part of my team and platform manager for Mahara) loves Rob's idea and has just described a field mapping function in ExLibris (Alma) that takes it further still, enabling field mapping which would enable it to solve other problems we are having too. For more details I'll invite him to comment.
Cheers,
Shane.

Revision history for this message
Kristina Hoeppner (kris-hoeppner) wrote :

The admin interface is the other option that could whitelist specific parameters. I'd still say that instead of throwing an error like it does right now for that specific parameter, it would be good if it showed up when the site is not in productionmode so that the admin knows what is currently ignored or causing problems and could then whitelist / ignore them in the admin interface.

Revision history for this message
Wangchen (tshering-wangchen) wrote :

With LTI, it would be nice to have some flexibility around field mapping.
Example, if we can choose to map Canvas UserID to Mahara username.

With Alma LTI on Canvas, for example,
 A. Allows custom field mapping
   1) Canvas Admin UI, pass customs fields. Screenshot attached named 'CanvasLaunch.png'
       ----
       lis_user_username=$User.username
       lis_course_offering_sourcedid=$CourseOffering.sourcedId
       ----

   2) Downstream on ALMA Admin UI, these fields can then me mapped - screenshot attached, named -
      'AlmaFieldMapping.png'
       Useful link: https://developers.exlibrisgroup.com/leganto/integrations/lti/canvas/admin

 B. Also, lets Admin debug the error by adding debug=true to the end of the LTI Launch URL.
 Useful link:
 https://knowledge.exlibrisgroup.com/Leganto/Product_Documentation/Leganto_Administration_Guide/Configuring_Leganto_Integration_Profiles/Configuring_Learning_Tools_Interoperability_(LTI)

Aside, there is a way around current issue, by tweaking the default Mahara XML(attached "MaharaLTIAccLaunch.xml") we can integration the LTI as is to "account_navigation" instead of the default "course_navigation".
Then grab the launch link from the "account_navigation" LTI and use it as you please, example via "Redirect Tool" - about redirect tool: https://www.eduappcenter.com/apps/63#.W3DFntgzbUI

Revision history for this message
Kristina Hoeppner (kris-hoeppner) wrote :

Hi Wangchen,

I think there might be a couple of wishlist items in your last posting rather than bug fixes, which might be good to separate out, but I'd have to take a closer look, which I can't do at the moment. We'd need to check if LTI allows for the mapping that you suggest. If I remember correctly, LTI did not and that's why we had to go with the way we did.

Please also note that Canvas may have customized it's LTI a bit. I know it's the case for the LTI homework assignment, and thus may have some additional things available that a standard LTI setup doesn't, which is the way we went for the initial implementation of LTI in Mahara to support the basics for the majority of LMSs.

In regards to your tweak, you can do that without any problems on your own instance of Mahara. I'd rather not include it in Mahara core as it doesn't fix the issue and might introduce problems for others that require the other parameter.

Revision history for this message
Wangchen (tshering-wangchen) wrote :

Dear Kristina,
You are right, it probably is a whishlist and not a bug.
It would be useful for institution(s) who rely on auth protocol(s) to autocreate users, as it will help make the user data consistent.

Just to clarify on the xml tweak, its not done on Mahara.
We use the updated xml content directly on Canvas (https://community.canvaslms.com/docs/DOC-12863-415274552) without consuming the mahara xml endpoint url (https://portfolio-stage.canberra.edu.au/module/lti/configxml.php)
I am just glad Mahara is flexible enough to accept this tweak.

However, it would be nice to have (whishlist) mahara LTI placements on all canvas navigations - user_navigation; course_navigation; account_navigation.
Gives our end user the launch flexibility depending on their need and convenience.

PS: I have tried XML tweak for the the navigation options: course_navigation and account_navigation works, but not user_navigation.

Thank you for your time.

Kind regards
Wangchen

Changed in mahara:
importance: Medium → Wishlist
summary: - LTI: Additional Canvas parameter is not ignored
+ Whitelist LTI parameters in site admin
tags: added: lti
Changed in mahara:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.