We usually guard such queries and have both mysql and sqlite branches. But I have not implemented the sqlite branch. Given sqlite is typically used for local dev setups, the fact that "users with more than the configured max simultaneous logins" can avoid getting some logins annulled is probably not a huge risk. And this always *used* to fail on sqlite, silently. Now, in php 8, it raises PDOException, which prevents running the test server Document this as a FIXME for now, until someone reimplements the query for sqlite. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> --- web/lib/acctfuncs.inc.php | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/web/lib/acctfuncs.inc.php b/web/lib/acctfuncs.inc.php index d238c0e0..30c4cfe0 100644 --- a/web/lib/acctfuncs.inc.php +++ b/web/lib/acctfuncs.inc.php @@ -597,7 +597,9 @@ function try_login() { /* Generate a session ID and store it. */ while (!$logged_in && $num_tries < 5) { $session_limit = config_get_int('options', 'max_sessions_per_user'); - if ($session_limit) { + # FIXME: this does not work for sqlite (JOIN in a DELETE clause) + # hence non-prod instances can have a naughty amount of simultaneous logins + if ($backend == "mysql" && $session_limit) { /* * Delete all user sessions except the * last ($session_limit - 1). -- 2.30.1