Answer the question
In order to leave comments, you need to log in
How to implement a ban in the role model (User - Roles)?
I have implemented users who have some roles
. When registering, the user automatically receives the role ROLE_USER
He can set ROLE_ADMIN, ROLE_MODERATOR, etc.
But I want to release a ban and I don’t quite understand how it’s done,
the essence of the ban is to prohibit certain actions, for example, write a message, put + under the message, etc.
Do I need to add ROLE_BAN and check every time? Or it is necessary to remove ROLE_USER?
Bans are also supposed to have several levels, the higher the level of the ban, the more actions will be prohibited.
How is a ban usually implemented in such cases?
Answer the question
In order to leave comments, you need to log in
You - described user roles.
You want to create ACL (access level system) roles that lower existing privileges.
First, create an ACL for all the user roles you described (USER_ACL, MODERATOR_ACL, etc.). This is a table with privileges (bit "mask" with powers of two): 1,2,4,8,16,32,64, etc. The sum of these values gives a number that uniquely identifies the ACL for accessing various functions.
Then - create different BAN-sets (ACLs for the same criteria).
BAN_CHAT, BAN_EDIT, BAN_DELETE, BAN_REOWNER, etc.
And subtract BAN_* from the current *_ACL.
Received - and there will be valid ACLs, but with restrictions on the BAN mask.
(less than or equal to 0 means no rights at all)
I usually made a "ban_level" column in the database for the home project and entered a number there depending on the level of restrictions for the person. And it has already been handled in the code.
1 - chat mut, 2 - account lock, 3 - reset your password, etc.
Then, a couple of years later, I made this approach: for each user, a column with restrictions was created, initially empty, as violations occurred, I wrote a string with restrictions there in json form (since it was impossible to divide into levels of restrictions, it was only possible to restrict various specific actions). Then each time I got it out of the database - and checked whether there is a restriction or not on the current action,
{"restrictions": { "chat", "levelup", "teleport"}}
As an option to make some kind of separate table of the
permission type, it will have rights, such as the right to put +, the right to edit the message ... The relation of the user table to permission is many to many. And thus we can issue any rights to each user. When registering by default, give rights to edit, add a message, etc. Or you can unwind everything in the opposite direction. All rights that are added are prohibited, all that are not added are allowed. Well, you can also separately think of what, for example, a user with ROLE_USER should ignore the rights values, for example, change the role of the user, ban the user (admin rights)
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question