Replies: 2 comments 1 reply
-
Thanks for your comments. I'm interested in hearing the rest of the team's thoughts, but I'll be honest - in the 15 years of doing freelance and agency work, I can't think of a single project that actually needed that granularity of organization. I've worked on some pretty big projects, but - to be fair - many were startups. My gut feeling is that the current solution works for 80%-90%+ of most use cases. I can definitely see the need to separate once you get into more enterprise type companies. However, do many enterprise companies use CodeIgniter these days? For small to medium style sites I would expect the current combination into a single "groups" object is enough. Additionally, I do have concerns about changing the central data structures at this point in the game. While it's still in beta, it's been out at least a year, I believe, and downloaded almost 30,000 times, according to Packagist. That seems a pretty large BC break for that many potential installs for what seems to me to be a very minor need for the types of users I feel like we have. |
Beta Was this translation helpful? Give feedback.
-
Hi Lonnie, true, there are use cases where a separation into groups and roles are not needed. But I have been involved in many others where that was the case. My thinking is that it can't hurt to have them. It would not change or remove anything from Shield but add a useful feature. I would say that it is better to add features now, while still in beta, than later. And since roles behave very much like groups, most of the code is already there. Best regards, |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I really like that the Shield project has been started and I am looking forward to its further development.
From my experience, authentication/authorization concepts usually involve
Groups are used to cluster users into logical or organizational units while roles are used to assign more global permissions.
Administrators can manage groups and their members from the GUI, e.g. "Marketing" or "Accounting". Roles and permissions
are more static and are either configurable via a config file (like in Shield today) or also via the GUI (with corresponding
database objects).
Having only one object combining the purpose of both, groups and roles, is easier to implement but harder to maintain
for the users of the app later.
Having roles and groups available allows to assign general permissions to the role "user" that
apply to all user accounts and in addition assign specific permissions to e.g. the "Marketing" group. In Shield today,
you would have to assign the same role permissions twice, to the "Marketing" group and the "Accounting" group.
I suggest to introduce roles into Shield that work the same as groups but that allow to differentiate between
role- and group-based permissions.
Beta Was this translation helpful? Give feedback.
All reactions