When session lock debugging and read only sessions deubgging are both
enabled, session lock debugging becomes moot. This patch causes
the session lock deubgging code to exit early if read only sessions
debugging is enabled.
The random retry delay for redis session cache was calculated as
rand(100000, 500000) giving an effective retry delay of 100 seconds
to 500 seconds. That's off by a factor of a thousand! Using Redis as a
session cache and when the connection hangs, you can get random
"cannot obtain session lock" errors because it's waiting up to
500 seconds (or about 8.33 minutes) for a Redis connection.
This sets the delay to the originally intended 100ms to 500ms.
(see MDL-59866).
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
Prior to this patch the debugging mode (when enabled) would trigger
on everywhere, regardless of whether or not READ_ONLY_SESSION is defined.
This patch modifies that behaviour so that the debugging only kicks in
if READ_ONLY_SESSION is defined and set to true.
If a developer has debugging on then they will recieve all debugging
messages for locking whether wanted or not. We already have a setting
to display these messages.
In 39770792ca read-only sessions were allowed.
In the redis case, as called from the mobile application,
this can lead to returning 'false' for session rather than ''.
CSRF protection for the login form. The authenticate_user_login function was
extended to validate the token (in \core\session\manager) but by default it
does not perform the extra validation. Existing uses of this function from
auth plugins and features like "change password" will continue to work without
changes. New config value $CFG->disablelogintoken can bypass this check.
There is an edge case whereby redis will fail
to accept connections on the first try but
retrying the connection seems to make it work
Included in this commit:
* Retry functionality in the session init
The redis session handler doesn't use the sessiontimeout config setting
to determine session lifetime.
It has a lock expiry, which is set to 7200 (or a config setting) that is
used to determine how long a lock is held onto, but that should be
distinct from the session timeout.
We should complete the deletion process using the same
user that started it.
Added a new param to loginas() to prevent the event to be generated as
there is no need to generate an new event for that as the user didn't
explicitly loginas again.
This is primarily because iOS has changed something under the hood which
means that only session cookies which have an expiry are passed around the
OS.
In order to make media playable outside of the browser (e.g. a video), we
must set a session cookie timeout.
Since the session timeout is configurable, this patch sets the cookie
timeout to the session timeout plus a period of one week.
This ensures that videos continue to work, and that the expired session
message is shown on the login page, but without requiring excessively long
session times.
