Send user name to LTI provider

[Gautam Bishwas]

HI All,
I am working on Moodle as LTI provider ,so that one moodle course can
also be accessed from consumer in my case consumer is also moodle my
question is ---Is any way exist in Basic LTI to send LTI username to
LTI provider.

Regards
Gautam Bishwas

[Sujay Daniel]

Hello,

We have a similar application that requires the username instead of the userid that's currently released. It will be great if this is a administrative option in the settings. What we have resorted to is to make the modification to the file but then we will have to keep up with the changes. I'm hoping this will be a added feature in future versions.

Thanks,

- Sujay 

[Stephen Vickers]

I also have applications which would benefit from this feature.  Whilst the LTI spec requires the user_id parameter to be an opaque value, there are use cases where usernames are more useful to pass and, if names and email addresses are being passed, then the opaquness of the user_id parameter becomes less of an issue, in my view.  For example, if a tool provider is being separately provisioned with user accounts from another system, the Moodle database key makes it impossible to match these accounts with a user launching via LTI.  Support for the lis_person_sourcedid parameter could provide an alternative solution as this should contain a value which is likely to have been used by an SIS to provision Moodle, if this happens.  I have some sample code to add username as an option for the user_id parameter which I am willing to pass on if this feature is something you are willing to support.  Please could someone from the project let us know their thoughts on this.

Thanks,

Stephen

[Nikolas Galanis]

Hi all,

as a rule, we are avoiding implementing functionality that is not contained in the formal spec of BasicLTI. Since it has admittedly been a while since I last checked the spec, I need to review if sending usernames is covered there. If it is not, I am afraid that we won't be adding it in the formal branch. You are, however free to do an unofficial branch and add it there.

I will check the spec sheet as soon as I can and if usernames are allowed, I will be adding the functionality myself.

Regards,

Nikolas

[Robert Russo]

I will have a solution for lis_person_sourcedid by the end of the day.

I will provide a patch against moodle 2.5 core LTI here as an attachment. It will upgrade perfectly and provide backup support along with all standard functionality to the username portion of LTI.

[Robert Russo]

https://github.com/lsuits/moodle/compare/misc_LSU_patches...lti_username_mod

[Robert Russo]

That was quicker than I thought.

[Jesus Federico]

Hi Nikolas,

I know it has been a while since this topic was raised but I came across this issue today with someone using Moodle and trying to connect to a Tool Provider I maintain using the username that must match in the two systems.

According to the spec the right place to put the username is lis_person_sourcedid

sic.
lis_person_sourcedid=school.edu:user
This field contains the LIS identifier for the user account that is performing this launch.    The example syntax of "school:user" is not the required format – lis_person_sourcedid is simply a unique identifier (i.e., a normalized string). This field is optional and its content and meaning are defined by LIS [LIS, 11].

And yes, it is optional, meaning that you don't need to send it in order to get certified as an LTI Tool Consumer. But, the true is that it is commonly required when you need a way for matching accounts in two different systems (the main idea of LTI 1.0 aka BasicLTI)

There are other LMS including this parameters (Sakai, D2L), so I think it is something you should consider to include in a further release.

For those looking for a quick (although dirty) solution, you only need to add a line to hock the parameter with the "Share launcher's name with the tool" option. In the line 271 insert

$requestparams['lis_person_sourcedid'] =  $USER->username;

The correct way to do this would be to add an option in Privacy to allow sending username, just like D2L does.

Regards,

Jesus Federico
BigBlueButton developer