TYPO3 Core

If you try to preview (show from backend) a page which is access protected by a frontendgroup when TYPO3 is powered by a PostgreSQL database an SQL error is shown instead of the page.

If a page is protected by a frontendgroup the preview link contains the ADMCMD_simUser parameter, where the value is the uid of the fe_group: https://example.org/home?ADMCMD_simUser=666

How to reproduce:

- Have a TYPO3 installation running with PostgreSQL
- Create a fe_group, set the home page as access protected by this fe_group
- Select the page in the backend pagetree and click "Show"
- instead of the page preview you see:

Oops, an error occurred!
An exception occurred while executing 'UPDATE "fe_users" SET "is_online" = ? WHERE "uid" = ?' with params [1651825132, 9223372036854775807]: SQLSTATE[22003]: Numeric value out of range: 7 ERROR: value »9223372036854775807« is out of range for type integer

This happens because the preview simulator fakes a frontend user uid using PHP_INT_MAX

// let's fake having a user with that group, too
$frontendUser->user['uid'] = PHP_INT_MAX;

and TypoScriptFrontendController->initUserGroups tries up update the is_online timestamp for this fake uid:

// For every 60 seconds the is_online timestamp for a logged-in user is updated
if ($isUserAndGroupSet) {
  $this->fe_user->updateOnlineTimestamp();
}

which fails for both MySQL and PostgreSQL as there is no such fe_user in "":https://git.typo3.org/typo3/typo3/-/blob/10.4/typo3/sysext/frontend/Classes/Authentication/FrontendUserAuthentication.php#L654

$dbConnection->update(
  $this->user_table,
  ['is_online' => $GLOBALS['EXEC_TIME']],
  ['uid' => (int)$this->user['uid']]
);

This is a problem for PostgreSQL as the default definitions of uid columns in tables, e.g. fe_users are defined as integer, not bigint.

https://www.postgresql.org/docs/current/datatype-numeric.html

integer: 4 bytes, typical choice for integer, range from -2147483648 to +2147483647
bigint: 8 bytes, large-range integer, range from -9223372036854775808 to +9223372036854775807

The immediate bug is easy to fix by not allowing to update is_online status if frontend_user-uid is PHP_MAX_INT.

Maybe we should consider though to change the columns referring to UIDs from integer to bigint.