A Moodle site accessing a webwork server I manage ran into a total failure of the LTI 1.3 authentication process after the Moodle server pulled in a recent commit added to the MOODLE_405_STABLE branch (the site is on 4.5.11+ so got that commit on a periodic pull of updates).
The underlying problem was that webwork makes the call back to the "authentication request URL" as a POST, while Moodle's session cookie (after the change) has SameSite=Lax so was not sent. Setting SameSite=Lax is now done for almost all clients.
The Moodle commit dropped the code which forced the Moodle session cookie to be set with SameSite=None for all modern Chrome browsers, and now forces SameSite=Lax (except for a special case).
I think that this change to Moodle also overrides any setting of session.cookie_samesite = "None" made in php.ini on the Moodle server. See the PHP documentation on session-set-cookie-params.
If that is correct, it is likely that any Moodle server which gets this recent Moodle code change will apparently run into problems with LTI 1.3 connections to webwork. (Similar code
The issue is under discussion on the Moodle LTI forum.
What is happening:
- Moodle is now explicitly setting
SameSite=Lax (except for a special case) on the session cookie.
- After the webwork server handles the "login" phase, it send the browser the self posting form to trigger the authetication phase.
- The browser send a
POST to Moodle's mod/lti/auth.php as its handling of the self posting form. Since this is a POST and the referred is webwork, the SameSite=Lax cookie policy forbids the browser from sending the Moodle session cookie.
- Part of the data is
repost set to 1 (set explicitly by webwork).
- Moodle receives the request without the session cookie.
- Without the cookie, Moodle cannot complete the handshake (it stores critical data for the process in the session data) and reports an Invalid request. When debugging settings are enables, the traceback shows a failure to retrieve the data needed to continue from the session.
Moodle has a fallback mechanism which is supposed to trigger a repost to itself in case the session cookie is missing on POST call to mod/lti/auth.php. However, the repost occurs (if I understand correctly) only when the form does not provide a value of repost. See: auth.php in Moodle 4.5
The temporary workaround was to force Moodle to back to setting SameSite=None (now for all browsers) just after where the main change was made in Moodle's lib/classes/session/manager.php.
It seems that a potential fix, at least for use with Moodle, would be to stop lib/WeBWorK/ContentGenerator/LTIAdvantage.pm from setting any value for repost in the self-posting form. Currently line 135 in main. Hopefully that would get Moodle to use its fallback mechanism (the repost to itself, which would get the needed session cookie).
@drgrice1 Do you know if setting repost to 1 was necessary to get webwork via LTI to work with some other LMS? Was it set for some other reason?
Note: Moodle's LTI provider code (when it is being used by some other LMS) apparently use a GET when calling the authentication phase - a decision which allows third party cookies to be sent (even when SameSite=Lax is active). However, using GET sends the "LTI handshake data" as URL parameters rather than as "form parameters" which I think is typically considered less secure.
Searches come up with a recommendation to make the settings site wide via php.ini by setting session.cookie_samesite = "None". I was unable to find any official instructions/guidance in the Moodle documentation site. As notes, that approach will be overridden by the explicit setting of SameSite=Lax in the revised Moodle code.
A Moodle site accessing a webwork server I manage ran into a total failure of the LTI 1.3 authentication process after the Moodle server pulled in a recent commit added to the
MOODLE_405_STABLEbranch (the site is on 4.5.11+ so got that commit on a periodic pull of updates).The underlying problem was that webwork makes the call back to the "authentication request URL" as a POST, while Moodle's session cookie (after the change) has
SameSite=Laxso was not sent. SettingSameSite=Laxis now done for almost all clients.The Moodle commit dropped the code which forced the Moodle session cookie to be set with
SameSite=Nonefor all modern Chrome browsers, and now forcesSameSite=Lax(except for a special case).I think that this change to Moodle also overrides any setting of
session.cookie_samesite = "None"made inphp.inion the Moodle server. See the PHP documentation on session-set-cookie-params.If that is correct, it is likely that any Moodle server which gets this recent Moodle code change will apparently run into problems with LTI 1.3 connections to webwork. (Similar code
The issue is under discussion on the Moodle LTI forum.
What is happening:
SameSite=Lax(except for a special case) on the session cookie.POSTto Moodle'smod/lti/auth.phpas its handling of the self posting form. Since this is aPOSTand the referred is webwork, theSameSite=Laxcookie policy forbids the browser from sending the Moodle session cookie.repostset to1(set explicitly by webwork).Moodle has a fallback mechanism which is supposed to trigger a repost to itself in case the session cookie is missing on POST call to
mod/lti/auth.php. However, the repost occurs (if I understand correctly) only when the form does not provide a value ofrepost. See: auth.php in Moodle 4.5The temporary workaround was to force Moodle to back to setting
SameSite=None(now for all browsers) just after where the main change was made in Moodle'slib/classes/session/manager.php.It seems that a potential fix, at least for use with Moodle, would be to stop
lib/WeBWorK/ContentGenerator/LTIAdvantage.pmfrom setting any value forrepostin the self-posting form. Currently line 135 in main. Hopefully that would get Moodle to use its fallback mechanism (the repost to itself, which would get the needed session cookie).@drgrice1 Do you know if setting
repostto1was necessary to get webwork via LTI to work with some other LMS? Was it set for some other reason?Note: Moodle's LTI provider code (when it is being used by some other LMS) apparently use a
GETwhen calling the authentication phase - a decision which allows third party cookies to be sent (even whenSameSite=Laxis active). However, usingGETsends the "LTI handshake data" as URL parameters rather than as "form parameters" which I think is typically considered less secure.Searches come up with a recommendation to make the settings site wide via
php.iniby settingsession.cookie_samesite = "None". I was unable to find any official instructions/guidance in the Moodle documentation site. As notes, that approach will be overridden by the explicit setting ofSameSite=Laxin the revised Moodle code.