-
Bug
-
Resolution: Deferred
-
Minor
-
None
-
4.1.10, 4.2.7, 4.3.4
-
MOODLE_401_STABLE, MOODLE_402_STABLE, MOODLE_403_STABLE
This issue is about granting 3rd party code more control over how the moodlesession cookie is set up, which is particularly useful when it's used in 3rd party contexts like LTI, mobile, others.
A brief history of the problem space:
- We landed SameSite=None to address Chrome 80 changes back in
MDL-67175. Cookies set with SameSite=None; Secure; will be included in 3rd party contexts. This was done in session management code and to the main moodle session cookie. We weren't sure of all impacted parties at that time (i.e. anything doing something with Moodle in a 3rd party context) but speculated it would be things like LTI. - Now, Chrome is in the final phaseout of SameSite=None, and 3rd party cookies set this way will no longer be sent in 3rd party contexts (right now, 1% of these cookie already are being dropped - see https://developers.google.com/privacy-sandbox/blog/cookie-countdown-2023oct). Soon this will be 100%. So, any code relying on our session cookies being set this way will soon stop working (or already has in 1% of cases).
- The alternative path for Chrome only (or one of the paths), is CHIPS (cookie partitioning mechanism - again, see above link for info).
- The relevant partitioning attribute is already supported in LTI, where a cookie check takes place and partitioned cookies are managed using a helper class located in auth_lti. This is localised to LTI and won't impact the session cookies unless detected during an LTI launch.
Right now, all the useful code lives in auth_lti. This code performs a cookie check, and only partitions a cookie if that particular mechanism is required. If LTI is used in a 1st party context (i.e. new window launch), this won't be required. If LTI is launched in Firefox, this won't be required. The important thing is that this is done conditionally. Doing it wholesale in session management code will cause issues.
Note also: PHP core hasn't even added support for this yet, so the method of setting it is currently quite crude (header juggling). See https://github.com/php/php-src/issues/12646 .
Now, fast forward to the present:
We're seeing reports of Mobile needing to do the same fix that LTI did (MDL-81405), and there are likely others which may need it too. Others which weren't identified clearly on the Chrome 80 issue.
This issue is scoped with providing a central API for the various plugins to use in order to properly setup/augment the Moodle session cookie with the relevant cookie attributes, should the respective calling code need the cookie to function in 3rd party contexts.
I don't know whether this will involve the cookie check itself, since that likely depends on the calling code's use case (e.g. LTI can be 1st or 3rd party and so conditionally sets this, Mobile might always be 3rd party in its use case so its cookie check might only try 3rd party mechanisms), but it certainly should include at least the means to hook in and augment the outbound cookie header, as needed.
Closely related work:
Firefox hint that they are changing their default SameSite=None to SameSite=Lax, which also impacts 3rd party uses in Firefox (see MDL-79712 where that was addressed, again in LTI land). When that will happen is unknown, but console messages suggest it will. It's therefore also worth considering making this API flexible enough to allow calling code to set SameSite=None; Secure; for cases other than the Chrome browser (which is the current criteria, per MDL-67175 changes)