Blocking just prevents someone from logging in.

If they are already logged in then you can force them to be logged out using the module on the dashboard

Would make sense though to force logout a user when blocking.
Let’s see if it is possible.

I can replicate this issue when Session Handler is set to PHP. Works fine when set to Database.

@sxzctzppyw
please confirm your Session Handler settings.

@infograf768
Session Handler is set to PHP.

I confirm the bug.
Also, and that is even more important imho, the force Logout from the admin module does not work when Session Handler is set to PHP (filesystem in j4)

Also, and that is even more important imho, the force Logout from the admin module does not work when Session Handler is set to PHP

I pointed this out years ago, this isn't anything new. The TL;DR is the force logout routine does nothing but query the session table and delete rows from there. Clearly this only works if using the database as a session handler, which for some reason, too many people seem to think is the only way people will use Joomla.

I pointed this out years ago, this isn't anything new.

Indeed I saw some old question about that.
I have no idea how to solve it when no path is given (system default tmp), but could not there be a way when we know the exact path of the file?

You should not be attempting to directly write to the session storage layer from anywhere outside the session API. You should be going through the session API. PlgPrivacyUser::onPrivacyRemoveData() is to my knowledge the only bit of Joomla code that gets any of this right, but this breaks on 4.0 because:

• Session metadata is optional, meaning you might not be able to get a list of all active session IDs for a user (which, is kind of a moot point in the first place because you wouldn't even have a list of users on the logged in user admin module without it)
• There is no singleton similar to JSessionStorage::getInstance(), nor should there be, and the fact that this exists in 3.x and earlier is an architectural design problem that is rightfully fixed (in a session class such as Joomla\Session\Session or Symfony\Component\HttpFoundation\Session\Session or Illuminate\Session\Store the session handler is an internal implementation detail of those classes and not expected to be a service generally accessible anywhere in your API, but because Joomla 3.x and earlier do not have a concept of dependency injection this forces parts of the API to expose methods to retrieve singleton service instances). The janky fix is to be able to do Joomla\CMS\Factory::getContainer()->get(\SessionHandlerInterface::class); and register this internal implementation detail as a global service, but that just recreates the architectural design problem, a better fix is to create some form of Joomla\CMS\Session\SessionManager class:

namespace Joomla\CMS\Session;

final class SessionManager
{
     /** @var \SessionHandlerInterface **/
    private $sessionHandler;

    public function __construct(\SessionHandlerInterface $sessionHandler)
    {
        $this->sessionHandler = $sessionHandler;
    }

    public function destroySessions(array $sessionIds): void
    {
        foreach ($sessionIds as $sessionId) {
            $this->sessionHandler->destroy($sessionId);
        }
    }
}

Still not architecturally "pure" as it still leaks the session handler as a service, and the DI Container doesn't have a notion of "private" services which can only be used in the context of building a service (a $container->set() type call) making it impossible to do $container->get() on any service anywhere in the application, but it's better than what exists in 3.x. Also, this type of method doesn't really belong on Joomla\CMS\Session\Session; Joomla\Session\SessionInterface (the parent interface for the CMS' Session class) is built to manage the active session for the user whose HTTP request is being processed, it's not a general purpose API for managing all sessions for all users active on the site.

Thanks for explanations. I'm afraid this is over my head.

Begrudgingly I have a patch almost finished to deal with force logout on 4.0.

Please test PR #26891

Look like the issue was solved elsewhere. I tried and it worked OK for Joomla 4, so I'm closing this issue. Feel free to re-open if you still have same issue on Joomla 4 (Joomla 3 is now in maintenance mode and only receive security bugs fixes, not normal bugs fix anymore)