Many developers will take this pattern and then implement a getPermissions() method in their application delegate class similar to the following:
To summarize this strategy, it entails:
- Returning the permissions assigned to the current user's role (which would be defined in the permissions.ini file).
- Returning no permissions if either the user isn't logged in or they don't have value in their 'role' field.
While this approach may work, it could open up some security holes if you're not very careful. Since you have defined the permissions in the application delegate class, these will be used as the default permissions for every table in the database. If you have some tables that include private information (which will likely be the majority of your tables), you would need to explicitly provide more limited permissions on each of those tables individually by implementing getPermissions() methods in their respective delegate classes.
A Better Approach : Default NO ACCESS; Grant More As Needed
A better approach would be to grant NO ACCESS to all users, except for administrative users, at the application level. Then you can grant additional permissions as needed at the table level. E.g.
This grants users with a role of 'ADMIN', all permissions in the system, and no access to anyone else.