I understand how to restrict entire pages, or even components by implementing <cflogin> and roles. For example:
<cfif IsUserInRole("Admin") OR IsUserInRole("Accounting")>
...You can view this page...
<cfelse>
...You can not view this page...
</cfif>
But how is it recommended to restrict certain facets of a page? Say for example an "Admin" is allowed to send Global Messages to all users, but that option is not available for a regular "User"
I suppose I could use the Session to manipulate my Views (pages). How is this typically handled?
You're right, securing a page and securing elements is different.
In my opinion and in practice, I think tying any code to a role or user is actually the wrong approach. Instead, tie permissions to elements and pages - then tie roles to those permissions. And of course, users are assigned roles.
It is important to have all three :
Users
Roles
Permissions <-- this is what you're missing
Permissions are what secure elements and pages, not roles or users Your code should have no clue (because it doesn't need to) what users or roles there are - just names of permissions.
When a user logs in, I grab their role(s). Then I grab all the permissions that are assigned to those roles (simply a list of string values).
For example, on a page I might have :
Add item
View item
Delete item
When I code that page, I actually secure each of those elements with permission strings named similar ( addItem, viewItem, deleteItem).
<cfif listContainsNoCase( session.permissions, 'addItem' )>
<!--- code to add item --->
</cfif>
(Note: I recommend using a custom tag or function for this, but for purposes of an example, the above works fine).
If you do it this way, it provides maximum flexibility and abstraction. If you secure elements based off of roles, you limit yourself :
Adding new roles will require a lot of code changes!
Changing permissions between roles requires a lot of code changes!
If you do it as mentioned above, you will never need to change your security code within the code base, because "addItem" permission should always be on the "add item" logic, right? :)
Now if you happen to need to create a "manager" type role, that has all the user roles and a select few admin rights, you simply create that role, and assign it the correct permissions (maybe addItem and editItem, but not deleteItem). Bam! Now I have a manager role to assign to users with no code changes!
If I had sprinkled my code with "is user this role" type of stuff - I would have to go edit my code everywhere to allow my new role "manager" - yuck!
Make sense?
=)
Things start going awry when businesses like to change the permissions that a Role has often because they don't know how else to give someone rights to do something.
So lets say a user in Marketing wants "update" rights to do some task. Someone in the business gives them the Update permission. But an IT Manager also has "update" rights which gives him access to things that the Update permission for Marketing should not.
So... I actually go one step further and specify Roles that have Permissions based on what Department that user is in. Yes its very complex and very tedious to manage hence I ended up on this question in my search for a better way to do it.
Related
I want to allow user to update data from form, but not from direct table. I added Before Change event on table, and raising error if the user group is 'basic'. This is working as expected if I enter data in table. But, it is also raising error even if saving data from form. Can anyone help me to resolve this issue?
Thanks in advance!
In general the way to deal with permissions in Access is to only ever show your users the forms; they should never directly interact with a table or query. So instead of adding Before Change code to your table, you instead want to hide the table.
The things you need are in the Current Database section of the Access options. For this example I'll assume you just have the one form, but the same applies if you have many forms and a "Home" form.
Use the "Display Form" dropdown to select the form you want the user to see when they open the application.
Un-check "Use Access Special Keys" to prevent keyboard shortcuts showing objects you don't want shown.
Un-check "Display Navigation Pane" to hide the object list.
Un-check "Allow Full Menus" to prevent users from creating new objects (or use other database development functions)
With this done, the user will see only the form interface you selected and the basic data entry toolbar.
Note that when you want to make changes to the file as a developer you must hold down Shift when opening the application, which will display the navigation pane etc. Of course, any user who knows about the Shift override could do the same. Which is why distributing in a compiled accde, which cannot be unlocked, is a good idea. But you need to set up the application using the above options before that matters.
In my Yii2 project previously I had worked on rbac, set it up as in the yii2 doc click here. Now I worked on different modules and I am back on rbac. Initially set it up with just sysadmin and staff. Now I want to add a new role along with the two previous roles. Which I did it auth_item table and assigned the user_id in the auth_assignmnet table to the new role created.
In my controller added the role name for which actions he can access. But still throws Forbidden Exception. Tried different things but unable to work on it..
Any solution for this?
First of all, you should modify RBAC structure using the provided authManager methods.
After adding new RBAC items manually in database or files you need to make sure cache is not keeping the old data.
Flush cache manually or call console method like
yii cache/flush-all
I'm trying to set up a custom content type in Bolt so that only the owner can edit their own record. i.e. to stop users editing each other's records.
I don't seem to be able to get the right combination of permissions in permissions.yml though.
Using:
contenttypes:
mycustomcontenttypes:
edit: [ owner ]
in the content-type-specific permissions lists all of the mycustomcontenttypes on the overview page when I'm logged in as an account that owns a subset of the records, but none of the records I own have the title wrapped in a link leading to the edit page and the "Actions" menu does not have the "edit" option.
I would have expected the "owner" role to exist in order to give owners permissions relating only to their own records - surely that's the point of that role?
Is it therefore possible to set my custom content type such that (outside of superusers like root, admin etc) only the owner can edit their content record?
Sorry for my english...
In my project I use ACL with SonataAdminBundle, but I can not understand why they did so, you need to have to create a record in the database, even when I want to use only Class-scope without Object-scope.
Also, when you create, for example, comments, SonataAdminBundle automatically creates an entry in acl_object_identities, it clutters up this action database.
I created a role that has the right to full access to all records in a table, regardless of who created the records, but SonataAdminBundle only displays them and prohibits editing.
The documentation for SonataAdminBundle reads:
because the object ACL permission is checked, the ACL for the object
must have been created, otherwise the AclVoter will deny EDIT access
for a non super admin user trying to edit another non super admin
user. This is automatically done when the object is created using the
Admin. If objects are also created outside the Admin, have a look at
the createSecurityObject method in the AclSecurityHandler.
But why? How to avoid this?
Do not want to write hooks.
Thank you in advance for any comments and help on this.
You can generate the object ACLs with php app/console sonata:admin:generate-object-acl
I'm trying to configure a Bugzilla instance, which will allow my clients to login, and file bugs for their website under development/maintenance.
For e.g: I have created 2 products called "TestProject", "TestProject2" and a user called "TestClient". What I'm trying to achieve is when TestClient logs in, he can only see TestProject, TestProject2 and only add/modify bugs in there.
TestProject, TestProject2 should not be listed for any other client.
I believe this has do with granular controls in the 'Groups' administration section, however I'm unable to figure it out.
Thanks
You are on the right track. This is the process I use and it works well for me.
Create a group for each of you clients.
Create or edit the product the client will use.
On the edit products page click "Edit Group Access Controls"
Select the following for the Group you want to have access
Enable entry, member control = mandatory, other control = mandatory, enable can edit.
Create a user and add them as a member of the new group.
To use this method all bugs have to be associated with a group like this or the users would see their bugs and any non group specific tickets.