TYPO3 Core

meanwhile you can use a hook as work around:

in ext_localconf.php:

$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_userauth.php']['logoff_pre_processing'][] = 'Tx_MyExt_Hooks_FrontendLoginHook->resetIsOnline';

in EXT:my_ext/Classes/Hooks/FrontendLoginHook.php:

<?php
class Tx_Jonastone_Hooks_FrontendLoginHook
{

    public function resetIsOnline($params, &$pObj) {
        $currentData = $pObj->fetchUserSession(true);
        if ($currentData) {
            $currentUser = $currentData['uid'];

            if (is_int($currentUser)) {
                $into_table = 'fe_users';
                $where_clause = 'uid = ' . $currentUser;
                $field_values = array(
                    'is_online' => 0
                );

                $res = $GLOBALS['TYPO3_DB']->exec_UPDATEquery($into_table
                    , $where_clause
                    , $field_values
                );
            }
        }
    }
}

Users who does not log out may not be identified correct. that problem can not be solved.
User who did a log out could be decided. but the core does not do it, so it is possible in an easy way (see hook).
It would be helpful to have at least this in the core

The 'is_online' state is updated for every 60 seconds, so timestamps older then 120 s (2min) can be read as not online anymore. An value of 0 means the user never logged in.

I think this should be enough. Do you have a scenario where a better solution is needed?

Since when is the status of a FE-user updated every 60 seconds?

the ticket was created for showing the availability of support members. They logged in in the FE to show up in the list and should be removed immediately on demand. they don't are active in the FE so no page refreshes and no updates of the field 'is_online'.
the availibilty is shown to visitors with a AJAX refresh every minute.

The only solution was the hook to clear the field at an explicit logout.

Ok, to clarify my statement:

Th 'is_online' value only gets updated with requests after 60 seconds and not on every request.

than your statement "so timestamps older then 120 s (2min) can be read as not online anymore." is wrong.
as a user who does not interact with the webserver between 60 and 120 seconds is wrongly considered offline.
maybe a user needs 3 minutes to read a page. is he offline? no!

either the fieldname is wrong (it does not hold the online state of the user and you can not clearly decide the status from the timestamp the field holds) -
or the behaviour must change in case you clearly can decide the state (= the user logged off explicit)

"can be read" ... that do not mean you MUST read them as offline.

Alexander Opitz wrote:

IMHO we need to split the meaning to 2 fields as "state online/offline" and "last seen online"

Splitting the field doesn't add information. The main difference between FE and BE is that in the backend a JS function regularly does an AJAX call to update the logged in status. In the frontend the CMS has no control over JS functionality so the only thing it can do out of the box is update it on each request.
If you really want to keep track of users that have a browser window open as "logged in" you can simply build some JS with a timer that does an AJAX call to a script that updates the field.

Shall we close this issue?

@Jigal van Hemert

The original issue is about the "logout" button. The user is still managed as "is_online".

regarding GDPR:
if the field contains information about the last contact to the server it holds more information than necessary.
especially if the user has terminated his session by using the logout button.

I wonder why this field can not change (Name and/or behaviour) while the core has changed with so many breaking changes since the origins or even since 6.2 (when this ticket was opened)

Anyway:
I don't manage that instance any more and there was a solution with the hook to get a correct behaviour.
Continue to tear down cities, but don't dare to touch a bird box.