Bug #91836
open
Backend user session is not deleted when user is deleted
0%
Description
Found on 9, is probably in 10 and 11 as well.
When deleting a backend user the potentially existing sessions are not deleted as well. Trying to delete such a session throws an exception becuase the user is missing.
(probably the same for FE users, could not test in my case due to lacking FE users on my setup)
Updated by Markus Klein over 4 years ago
- Status changed from New to Needs Feedback
How do you try to delete a session?
Updated by S P over 4 years ago
Module BE users. Dropdown at top: Logged in users. There are buttons to kill the sessions.
When you click the button for a deleted user you get an exception that the user does not exist. At first this sounds correct if one does not think further about it - but instead the session should not be there in the first place (how can a non-existing user have a session?)
And just for data integrity reasons, in general: all "sub-records" only belonging to a parent record should be deleted when the parent record is deleted. Sessions data can be seen as a bidrectional 1:1 relation to its BE user.
Updated by Markus Klein over 4 years ago
- Category changed from Authentication to Backend User Interface
- Status changed from Needs Feedback to New
Thanks.
Yes the session could be deleted immediately and the UI shouldn't show the session if the user is not there anymore.
Nevertheless the stale session is not a problem in data integrity perspective, because the session can't be used anymore if the be_user is already gone.
Updated by S P over 4 years ago
Nevertheless the stale session is not a problem in data integrity perspective, because the session can't be used anymore if the be_user is already gone.
Of course it is. If not, you could also just claim that inline records can stay when their parent record is deleted. "because they can not be used anymore".
I want a clean database and clean "data flow". I do not want a self-proclaimed "LTS enterprise" system which then, however, says "it's not that bad if dead data is not deleted". Especially anything authentication related: it just opens/leaves an unneeded attack vector that maybe could become a problem if spomeone discovers a security flaw which we do not think about now.
Updated by Markus Klein over 4 years ago
Well, did you consider that sessions are collected by their timeout usually? So those data should really not stay stale for a long time.
Besides that, of course things can/should be improved.
Feel free to push your suggestion to Gerrit anytime.
Updated by Shehfinaz Kadavil over 2 years ago
Could not reproduce the issue. Tested with two users A and B in two browsers. Deleted user A as user B. Then reloaded User A's browser and was automatically logged out.
Updated by Markus Klein over 2 years ago
- Status changed from New to Needs Feedback
Updated by S P over 2 years ago
- TYPO3 Version changed from 9 to 10
Shehfinaz Kadavil wrote in #note-6:
Could not reproduce the issue. Tested with two users A and B in two browsers. Deleted user A as user B. Then reloaded User A's browser and was automatically logged out.
You did not correctly understand the problem. Of course TYPO3 can not load the user data and thus does not authenticate him if the suer is deleted. The issue is that the database table row that holds the session data (which si a different database table then teh users) does not get cleaned up when a user is deleted.
User table has user "A"
Session table has session data for user A.
Delete User A.
Session table keeps session data for user A. This is the reported issue.
Updated by Markus Klein over 2 years ago
- Status changed from Needs Feedback to Accepted