WeBWorK Main Forum

Using LTI while also not using it

Re: Using LTI while also not using it

by Alex Jordan -
Number of replies: 0
Thanks everyone, today I met with our Brightspace team leader and it appears we have single sign-on working. It's not live here for a little while because it needs to go through standard security and accessibility evaluations. But we hope to have it live by the time our Fall term starts (Sep 29). I'm going to wait on grade pass back until Winter term.

I have one issue to report, which may be of use to others, or may be a symptom of me mismanaging git over the years. I pulled master this morning which has PR#726 in it now at its head. This pull resulted in a conflict in
lib/WeBWorK/Authen/LTIAdvanced.pm

around line 366 where I had formerly had these lines:
- # append the path the the server url
- $path = $path.$r->urlpath()->path;

and the pull wanted these lines to got there instead:
+ if ( $ce->{debug_lti_parameters} ) {
+ warn("The following path was reconstructed by WeBWorK. It should match the path in the LMS:");
+ warn($path);
+ }


The additions are clearly from #726. The two deletions do not exist in master, but do exist in develop. So I guess I pulled develop into my repo at some point earlier this summer, then pulled master with #726 leading to this conflict.

After I addressed the conflict and deleted these lines, single sign-on was not working. Following the LMS to a WeBWorK link took me to the login screen with a message about failed authentication. Once I added these two lines back in (right above the #726 added content) then it all works. If anyone finds themselves in a similar situation (where you have been sometimes cherry picking develop commits on top of master) then maybe you will want to check for these lines.

Danny, thanks for the D2L specific instructions. I think there will be some minor differences from one version of D2L to the next. For instance I had no "
Send system role to tool provider" option to check. I had "Send system Org Defined ID to tool provider" which I checked, although I'm not sure if it mattered. And when my colleague was working in our D2L testing environment which is an even newer version, there were even fewer of these options to check. His guess was that many of them are now passed no matter what.