Installation

Webwork and LTI

Webwork and LTI

by Mark Hamrick -
Number of replies: 3
I am attempting to integrate Webwork with Canvas using LTI. When I click on the assignment, I get the following error:

OAuth verification failed. Check the Consumer Secret. at /opt/webwork/webwork2/lib/WeBWorK/Authen/LTIAdvanced.pm line 401.

I have verified the consumer secret is correctly set.

I have set the preferred_source_of_username to a different field, however I am noticing that the User id is still the lis_person_sourcedid.
In reply to Mark Hamrick

Re: Webwork and LTI

by Danny Glin -
That error message may be misleading, as the consumer secret isn't the only thing that can cause the verification to fail.  In my case it was a matter of $server_root_url not being set correctly in site.conf, so that may be the culprit in your case as well.

Note that the way the LTI module is coded preferred_source_of_username can't currently be set to an arbitrary field.  The only value of this variable which will change the behaviour is "lis_person_contact_email_primary".  I'm hoping to modify this to accept any field, but I can't promise that this will be done in the immediate future.
In reply to Mark Hamrick

Re: Webwork and LTI

by Paul Pearson -
Hi Mark,

Today, I worked with my system administrator to get Moodle and WebWork sharing information with each other via LTI.  We were having problems very similar to the ones you mentioned (we got the same error message you did).  With the help of Geoff Goehle, we were able to find and fix the problem.  Danny's advice is probably what you need to fix the problem, but his answer might not be specific enough to make sense until you know what he means.

Here's the short answer: try using secure "https" instead of unsecure "http" in all of your configuration files and URL settings.

Here's the long answer:

LTI authentication does not like address forwarding for obvious security reasons.  (For instance, if LTI permitted address forwarding, then the credentials LTI provided to log in to http://webwork.yourschool.edu/webwork2/best_math_course_ever/ could get forwarded to http://evil.hackers.anonymous.org/, which is not safe!)   Your webwork server should be using secure https protocol (notice the s in https), not unsecure http protocol (notice there is no s in http).  The default configuration files that come with webwork typically have values for unsecure protocols such as "http://webwork.yourschool.edu" instead of secure protocols such as "https://webwork.yourschool.edu".  So, when you configured your system, you may have had configuration files that say "https" in some spots and "http" in other spots.  You managed to get the server to work, not noticing that those "http" settings were having their address forwarded to "https" automatically by the web server when scripts were run.  Well, LTI will not tolerate discrepancies between "https" and "http" -- you've got to change everything over to "https" if you want a secure web server.

So, what's the fix?  In the WebWork files site.conf, localOverrides.conf, and authen_LTI.conf you need to make sure that every "http" is replaced by "https".  Also, when you create the "tool" or "link" in Canvas that actually does the LTI authentication (in Moodle this is called "External tool"), you need to make sure that the webwork course URL provided uses "https" secure protocol.

Please let us know whether you've gotten Canvas to authenticate logging in to WebWork via LTI.

Take care,

Paul Pearson
In reply to Paul Pearson

Re: Webwork and LTI

by F. Heiderich -
I also experienced a variation of this problem. My configuration was:

$webwork_url = "/webwork2";
$server_root_url = "https://webwork.myschool.tld/";

I used https://webwork.myschool.tld/webwork2/coursename/ as URL in the LMS.

The problem was that webwork apparently concatenated $server_root_url and $webwork_url to obtain

https://webwork.myschool.tld//webwork2

This did not match (the beginning of) the URL

https://webwork.myschool.tld/webwork2/coursename/

Removing the final slash in $server_root_url solved the problem. I think that it might be helpful to mention in site.conf that no trailing slash should be used in $server_root_url (if one should not use one).