Store and Get list of groups and permissions in DB and Assign permissions to groups with a web interface.

[mouaad19]

Since Shield does not use the "auth_groups" tables to store the list of groups and "auth_permissions" to store the list of permissions and the "auth_groups_permissions" table to assign permissions to groups, it uses the setting() package Instead, ( Config\AuthGroups, groups or permissions and matrix to assign permissions to groups.)

so my question is : Why not use these previous tables as myth-auth (it was easy to manage all this from a web interface)?

I tried to create a web interface to list, create and edit permissions and groups and manage assignments, but unfortunately it was very difficult to work with this new architecture because I am a beginner so I ask you if it Is there anyone who has an idea or help me develop this web interface.

thank you

[lonnieezell]

It just has a different set of goals.

For a working example of dealing with user/group permissions, please check out Bonfire's Users and Groups code.

[mouaad19]

It's an honor for me that @lonnieezell answered me. Thank you very much, that's exactly what I was looking for.

[kenjis]

See also

• https://github.com/codeigniter4/settings/#usage
• https://github.com/codeigniter4/settings/#using-the-helper

[bgeneto]

Since Shield does not use the "auth_groups" tables to store the list of groups and "auth_permissions" to store the list of permissions and the "auth_groups_permissions" table to assign permissions to groups, it uses the setting() package Instead, ( Config\AuthGroups, groups or permissions and matrix to assign permissions to groups.)

so my question is : Why not use these previous tables as myth-auth (it was easy to manage all this from a web interface)?

I tried to create a web interface to list, create and edit permissions and groups and manage assignments, but unfortunately it was very difficult to work with this new architecture because I am a beginner so I ask you if it Is there anyone who has an idea or help me develop this web interface.

thank you

IMHO, this was an unfortunate decision of Shield's developers (not having proper tables for users_groups and permissions). It is still a pain (so much work) to simply edit (change) an existing group using the settings service. Remember that one cannot delete a single key from the AuthGroups.groups array in settings with forget() or any other method AFAIK, also an update operation that changes e.g. a name/key have to delete the whole AuthGroups.groups array and insert it again while keeping record of which key has changed. Additionally, If you already have a CRUD library (like Grocery CRUD) you will not be able to use it with groups and permissions in Shield... That's why @lonnieezell myth-auth is still (and will ever be) relevant to me.

[jozefrebjak]

@bgeneto I disagree with you. While I agree that using myths can be an option, I still believe that Shield is a better choice in most cases. However, it's important to consider the specific use case and not just default to a CRUD approach.

It's true that not everything needs to have a table, and Shield's design is definitely worth exploring. In fact, Shield groups mechanism can provide a powerful way to manage permissions and access control.

[glewe]

I can see arguments for both opinions here. If Shield is meant to be a basic and simple approach it does its job. Developers can extend it with their own code. If it shall grow into a more capable and featured auth solution then it should introduce database tables and a UI to manage them.

I also worked with Lonnie's Myth-Auth for that reason. I actually expanded it with my individual extensions as CI4-Auth.

[kenjis]

Shield assumes that groups and permissions are not very numerous or frequently changed
(or group/permission names are never changed).
Settings library is for storing configuration values in a database and does not scale.

This design is problematic in a system where groups (roles) are large or change frequently.
Tables are not normalized and Shield stores data as strings, which is inefficient.

[bgeneto]

Shield assumes that groups and permissions are not very numerous or frequently changed
(or group/permission names are never changed).
Settings library is for storing configuration values in a database and does not scale.

This design is problematic in a system where groups (roles) are large or change frequently.
Tables are not normalized and Shield stores data as strings, which is inefficient.

couldn't agree more... 💯