fix: correct IP cast bug in update_session causing login failure

[darknoon29]

Problem

After resetting a user's password directly in the database, login was failing with "Unidentified visitor" even though authentication logs showed the password verification succeeded.

Root Cause

In Sessions_Model::update_session(), the $user_ip parameter was cast to bool before being used in the SQL WHERE clause:

$user_ip = (bool)$user_ip;  // "82.67.34.73" → true
// ...
$request .= " and `session_ip` = '" . $user_ip . "'";
// → WHERE session_ip = '1'  ← never matches the real IP

This caused the UPDATE to match zero rows, leaving user_id = 0 in the session. The subsequent SELECT in select_user_data_session() then found the session row but with no linked user → "Unidentified visitor".

Fix

Removed the erroneous (bool) cast. The IP string is now properly escaped with sql_escape_string() only when it is actually provided (i.e. not false).

if ($user_ip !== false) {
    $user_ip = $this->db->sql_escape_string($user_ip);
    $request .= " and `session_ip` = '" . $user_ip . "'";
}

Files Changed

• model/Sessions_Model.php — update_session()

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

Fixes a login failure where sessions were not being updated due to an incorrect boolean cast of the IP address in Sessions_Model::update_session(), preventing the UPDATE ... WHERE session_ip = ... clause from matching the real session row.

Changes:

• Removed the erroneous (bool) cast on $user_ip in update_session().
• Updated the IP filter logic to only append the session_ip predicate when $user_ip is explicitly provided (!== false), and to escape it before use.

[Copilot]

Add PHPUnit coverage for this bugfix (e.g., assert that when an IP string is provided, update_session() builds the UPDATE with session_ip = '<escaped ip>' and does not coerce it to a boolean). The repo already has unit tests for other models with mocked DBs, but there is no regression test ensuring session updates match the correct IP, so this could silently break again.