User tests: Successful: Unsuccessful:
Partial Pull Request for Issue #26539
Force logout of a user does not work consistently unless you are using the database as your session handler. This pull request for 4.0 refactors the system to ensure all functions work with all handlers.
The session handler used internally by Joomla\CMS\Session\Session
is now exposed as a service, this should never be direct accessed but is needed to make the new manager class work.
The Joomla\CMS\Session\SessionManager
class is introduced as a means for allowing someone to destroy a session's data using the session handler.
The "User - Joomla!" plugin is adjusted to use the new session manager to handle session destruction when deleting a user or when the force logout option is enabled at logout (contingent on session metadata being available).
The "Privacy - User" plugin is adjusted to do the same when removing data (currently this will fatal out because the plugin tries using the no longer existing JSessionStorage
class).
If the DI container services are being documented, make it clear as day that nobody should EVER, EVER, EVER direct access the 'session.handler' service (or any of its aliases). Introducing the concept of private services to the container so that this service is only accessible in the scope of a service factory would be a good way of preventing this, but if not added to the container before 4.0 then the feature is useless until 5.0 because if introduced, moving a service from public to private should be considered a B/C break (in the same way moving the visibility of a class method or variable from public to protected or private would be one).
Status | New | ⇒ | Pending |
Category | ⇒ | Libraries Front End Plugins Unit Tests |
Labels |
Added:
?
?
|
Just am testing, but in J4 I don't see an icon to force-logout users in the Logged-in Users module. Is there any other way to force-logout a user as described in testing instructions above?
@richard67 You have to login to frontend.
Forced logout seems not to work for me. Sessian handler is database.
But maybe I just don't understand function right? After using the button and closint the browser window where the other user was logged in to frontend (on other VM with different IP adress), the logged in users module shows me the user is gone, but when I open again the browser window on the VM, the other user is still logged in when going to the site.
Record in session table in db are not deleted, only user id is set to zero. But that might be the normal way it works, I have no idea.
If you refresh the page after getting logged out, you start a new session as guest.
Hmm, yes, that explains the records in db. But still I have the problem when I refresh the page as the other user in the other browser at the other VM after I have forced logout this user user, I am still logged in as that other user.
I have tested this item
Force logout doesn't work correctly on Filesystem handler. Have same result as described above. @richard67 are you getting this issue when using Filesystem handler? Database works fine for me.
@SharkyKZ It's funny: I get the error when session handler is database, and I don't get the error when session handler is file system, just vice versa as you have it. But we are located in the same hemisphere of the globe, so it can't be a north south issue like it is with seasons and weather ;-)
Hmm, does not all work with filesystem, user was logged in with two sessions in different browsers on different hosts, and forced logout logged out only one of the two sessions. And metadata was switched on.
Am testing with Linux, PHP 7.2, MySQL 5.7.
Problem is I haven't done a test yet without this PR so I can't say which issues are old and which are new.
I don't have the bandwidth to do anything more with this. Someone else is free to either build on this or ignore the issue it attempts to solve.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-01-01 17:41:50 |
Closed_By | ⇒ | mbabker |
I have tested this item✅ successfully on fa5cd77
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/26891.