There are also a few general corrections to PHPDocs that I noticed along
the way (e.g. adding `|null` when the method is returning a null value.
There are some cases where either the return type or the whole PHPDoc
was duplicated from the parent class - in those cases I've simply
removed the duplication.
A potential account hijacking may happen if an attacker has physical access to
victim's computer to perform session fixation. Also possible if the targeted application contains an XSS vulnerability.
Requires the victim to click the password reset link sent to their email.
If all the above happens, attackers may reset the password before the actual user does that.
Fixes regression from 3.x, where sessions where lazy started as required:
Either because an existing session identifier was sent through with the request,
or because new session data needed to be persisted as part of the request execution.
Without this lazy starting, *every* request will get a session,
which makes all those responses uncacheable by HTTP layers.
Note that 4.x also changed the $data vs. $changedData payloads:
In 3.x, they both contained key/value pairs.
In 4.x, $data contains key/value, while $changedData contains key/boolean to declare isChanged.
While this reduces duplication in the class, it also surfaced a bug which was latent in 3.x:
When an existing session is lazily resumed via start(), $data is set back to an empty array.
In 3.x, any changed data before this point was *also* retained in $changedData,
ensuring it gets merged into existing $_SESSION data.
In 4.x, this clears out data - hence the need for a more complex merge logic.
Since isset($this->data) is no longer an accurate indicator of a started session,
we introduce a separate $this->started flag.
Note that I've chosen not to make lazy an opt-in (e.g. via start($request, $lazy=false)).
We already have a distinction between lazy starting via init(), and force starting via start().
In scenarios where:
- No member is logged in
- An 'AutoLoginHash' is provided via the 't' (token) query param
- The token isn't valid (determined by Member::validateAutoLoginToken())
The message which is intended to be returned to the end-user via $Content
in the template, is mistakenly double nested in ['Content' => ['Content' => 'Message']]
this leads to "The method forTemplate() doesn't exist on ArrayData" errors.
See - https://github.com/silverstripe/silverstripe-framework/issues/7866