WeBWorK Main Forum

LTI issue on 2.16

LTI issue on 2.16

by Balagopal Pillai -
Number of replies: 7

I have webwork 2.16 running on a test server. This was upgraded from a previously working 2.14 setup that uses LTI with brightspace. One of our instructors is testing this new version out and stumbled on an issue with LTI. 

Basic LTI functionality works. It is possible to post the homework set in brightspace and see the list of problems. Once a problem is clicked, it gets bumped back to webwork login page. The url the instructor sees on a problem is the following -


https://server-url/webwork2/course-name/homeworkset-name/problem-number/?effectiveUser=instructor-username 


instead of 


https://server-url/webwork2/course-name/homeworkset-name/problem-number/?effectiveUser=instructor-username.....&key=a-long-string


        I tried debug lti parameters and only thing I saw was a warning like this in the log - 

                The following path was reconstructed by WeBWorK.  It should match the path in the LMS:

        

        

        Any help is much appreciated. Thanks. 

       

In reply to Balagopal Pillai

Re: LTI issue on 2.16

by Glenn Rice -

If your WeBWorK server is configured to use session cookies, then the url will no longer contain the key.  You may need to check your cookie settings in localOverrides.conf.  The defaults are to use SameSite Lax, Secure false, and a 7 day expiration period.  You may need to change those settings.  On my server I change Secure to true (set CookieeSecure=1 in localOverrides.conf).

From what you say, it seems that the initial LTI authentication succeeds.  The behavior you describe sounds like an issue with the cookie settings.

In reply to Glenn Rice

Re: LTI issue on 2.16

by Balagopal Pillai -
Thanks a lot. I have changed the cookie settings in localoverrides conf file. Seems like it is a new option and I missed it when looking through localOverrides.conf.dist! I have set it to the following and requested the instructor to test again -

$CookieSameSite = "Lax";

# Set the value of the secure cookie attribute:
$CookieSecure = 1;


An update to the issue without the cookie setting above - Our instructor has reported that posting the assignment as an external resource in brightspace solves the LTI issue. Thanks again.
In reply to Glenn Rice

Re: LTI issue on 2.16

by Larry Riddle -
We have a student who is also running into this issue of getting bumped to the WeBWorK login page rather than to the problem set. In our case she is authenticating through Canvas. I had a similar problem back in July when doing some testing after I upgraded our WW server to 2.16, but I fixed it making the changes to the cookie settings in localOverrides as described here, so I was surprised when this message came in today from the student's instructor. Checking WeBWorK shows that other students in the class have successfully been completing the assignment.

Doing some additional testing as a student enrolled in the instructor's course, I discovered that the issue did NOT occur when using the Firefox browser on a Mac, but DID occur when using the Safari browser (which is what the student was using). I further verified that the issue also occurred when using Safari on an iPad.

So what would be causing Safari to send the student to the WW login page, but not Firefox? Is it something about how Safari handles cookies? My localOverrides settings are
$session_management_via = "session_cookie";
$CookieSameSite = "none";
$CookieLifeTime = "session";
$CookieSecure = 1;
In reply to Larry Riddle

Re: LTI issue on 2.16

by Larry Riddle -
More testing revealed that this issue with Safari with the student getting bumped to the login screen when clicking on a problem in a homework set happens only when the assignment in Canvas is set to open the WeBWorK page directly in Canvas rather than in a new browser window. Balagopal, is that what you meant when you wrote that posting the assignment as an external resource in brightspace solved the LTI issue? In Canvas, the use of WeBWorK is called an "external tool".
In reply to Larry Riddle

Re: LTI issue on 2.16

by Danny Glin -

In Brightspace, the use of WeBWorK is also called an "External Learning Tool".  When you create a link to an external tool in Brightspace, there is a checkbox to "Open as External Resource".  Checking this box does a couple of things, one of which is that it causes the tool to be opened in a new window.

FWIW I'm using WW 2.16 with Brightspace with the default cookie settings, and I am unable to reproduce the Safari issues, even when opening WW inside a Brightspace page.

In reply to Larry Riddle

Re: LTI issue on 2.16

by Balagopal Pillai -
Have a look at this url - https://github.com/openwebwork/webwork2/issues/1072 From this link, it does seem that posting as an external resource might have opened a new window and this issue is solved when that happens. The instructor reported the issue
as fixed using the external resource option even before I made the cookie setting changes. After I set CookieSameSite as None, the instructor tested again posting the webwork url same way as he used to with 2.14 as a non-external resource and it worked.
Just a question - Are webwork config files case sensitive? You have posted CookieSameSite = "none"; I set it as None with an upper case "N".
In reply to Balagopal Pillai

Re: LTI issue on 2.16

by Glenn Rice -
The case doesn't matter.  That setting is set as the SameSite attribute of the cookie as is by WeBWorK.  The SameSite attribute works the same with the setting of "none" or "None".  All values in headers (including cookies) are case insensitive.

One option that could be tried if session cookies are causing issues is to instead use session management via keys.  I.e., the traditional method.  Set $session_management_via = "key"; in localOverrides.conf for this.