The MoodleSession cookie is already set this way when using Chrome, but
not for Firefox. This is a decision made in \core\session\manager. When
Firefox eventually defaults to SameSite=Lax when the SameSite attribute
is omitted from the Set-Cookie headers, the MoodleSession cookie won't
be sent. This change ensures the cookies used during LTI launches will
continue to work if/when this happens, and despite any changes which may
be made to core's sessionlib in future.
Adds the property that is required by Chrome to opt-in to its 3rd party
cookie partitioning solution, CHIPS. This specific change to auth_lti is
to ensure the MoodleSession Set-Cookie header resulting from
complete_user_login() calls (in auth.php) have this property set.
To opt a cookie in to Chrome's 3rd party cookie partitioning solution,
CHIPS, the property 'Partitioned;' needs to be set. This adds a helper
class supporting this, for a given cookie(s).
Note also, PHP's native
cookie APIs (setcookie, etc) don't support this cookie property yet -
(https://github.com/php/php-src/issues/12646).
Since this class is intended to allow existing Set-Cookie headers to be
modified before being sent (e.g. allowing clients to set a property on a
cookie set elsewhere in code), it deals with the headers directly anyway
but it means that new cookies must also use this helper to opt-in,
instead of relying on setcookie(). E.g. where the intent is to add
partitioning support to a new cookie, that cookie must first be set
(setcookie) and then it may opt-in to partitioning via this helper;
partitioning support cannot be achieved directly through setcookie and
friends yet.
Browsers are phasing out 3rd party cookies. Those which can be set are
partitioned to the top level embedding site, so piggybacking is
prevented. This will break the account linking process. This fix swaps
the piggyback for a login round trip, as originally intended, which
resolves the issue.
If an existing session is active at the time of launch, that user id
appears in the user_updated log. This log should show the launching user
updating their own record, not someone else. To resolve this, auth the
user before making any record updates so that the event gets the correct
user id.
If an existing session is active at the time of launch, that user id
appears in the user_created log, incorrectly (it should be system/0).
This patch makes sure that any existing session is terminated before
creation of a new user during launches.
When receiving data from the LTI launch, or service call, only update
the user record when we know something has changed. This prevents the
creation of many \core\event\user_updated events.
This isn't required and generates excess events. The only thing update
does, other than update the user fields, is to update the picture, but
in this case, that's unset in membership-based auths anyway, so it's
entirely safe to remove this.
Three modes are initially introduced here, for use by dependent code:
1. Automatic - where accounts will be automatically created for users
2. Prompt new or existing - where the user can choose to use an existing
account or have a new account created for them.
3. Prompt existing only - where users must link an existing account.
This change also adds linked logins, for use with provisioning.
version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in master, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.
