I have a browser:page setup in Zope, and I have:
permission="zope2.Public"
My question is what should I change this to in order to allow only Plone administrators access, and/or logged in (non-administrators) access to this page?
On Zope, you control access to views via permissions, but to permit someone to access a given permission, you must grant such permissions to a role.
Anyone in the Plone administrators group has been granted the Manager role (on Plone 4.2 that'll change to the SiteAdmin role) generally have access to most permissions. There is also the automatic Authenticated role, which is given to anyone that has been authenticated (has logged in). The latter doesn't have many default permissions though.
Permissions are generally named after the action you want to permit. If your view's goal is to manage some aspect of your Plone portal, then the cmf.ManagePortal permission is probably what you want. You can check the full list of default permissions if you need another one.
There is some excellent documentation on how security works in Plone, which includes information on how to define new permissions too, and how to assign existing permissions to roles.
permission="cmf.ManagePortal"
This setting is about permissions not about roles.
Related
I am building a site on Liferay 7. By default, all the authenticated users inherit the Guest permissions (anonymous users).
There is even a label in the permissions section:
"Under the current configuration, all users automatically inherit permissions from the Guest role."
Why do I need this?
I would like to display X content only for anonymous users and when the user logs in, then I would like to display different content.
This is how my content permissions for anonymous users are configured:
Although I agree with people that say this is not the best path, yes you can do it - just to address the question at hands.
Set this to true if resources should assume that all users have the Guest role. Set this to false if resources will not assume that all users have the Guest role and, thus, do not automatically inherit permissions that belong to the Guest role.
Setting this property to false may require users to grant permissions to roles like Site Member and User.
Defaults:
permissions.check.guest.enabled=true
Why do I need this?
Permissions are not the catch-all for showing different content. If a guest is not allowed to see something, but needs to log in - that's fine. It's authenticated content, and you'll need to sign in.
If an authenticated user has no permission to see certain content, but just needs to log out in order to see it: What kind of permission is that? Let me answer that for you: It's not permission. It's rather targeted content and while it might be mimicked with permissions, this mimicry is nothing more than mimicry.
One way to implement such a requirement is through structured Web Content (you sound as if you want to show different Web Content articles). The template has access to the full API and can check if the current user is signed in or not - and show different content based on this fact.
If you want to achieve role permission using code level as like in xxxlocalserviceImpl class.You can use below code for allow permission for the guest user.
In case of document and media allow permission to guest and registerUser in Liferay 7 using rest webservice you can use this code for allow permission to upload and download the document using this code.
ResourcePermissionLocalServiceUtil.setResourcePermissions(companyId,
DLFileEntry.class.getName(), ResourceConstants.SCOPE_INDIVIDUAL,
String.valueOf(dlFileEntry.getFileEntryId()), guestRole.getRoleId(),
new String[] { ActionKeys.VIEW });
To answer your question - you can not configure that per specific asset! By default an authenticated user can not have less permissions than an unauthenticated one. You can change that behavior for all assets using permissions.check.guest.enabled=false as #Victor correctly pointed out!
I need to give permissions to edit/create/destroy pages in a node to a group of users.
I've created a group and added a test user to that group.
I can't seem to give permission to the Pages application so see if i can see the node.
I also added game this role permissions at the node level too.
Ideally this editor role would be able to create new sub pages, which also means being able to upload media.
Your new user must have editor privilege level (you can edit user in Users application). If you want to provide ability to see content in Pages app you have to grant the user with Browse tree and Read permission (content module). To satisfy your scenario you need to grand user with Modify and Create permissions, too (maybe Design?).
Just FYI: The approach provided by Brenden (cloning the role) is very handy but there a is chance you grant the user with permission you don`t want to provide (inappropriate permissions for original role).
I've found the most efficient method is review the out of the box roles provided by Kentico and clone the one which fits closest to your needs. Then modify your cloned role to add/remove abilities and permissions.
If you're unsure of what each role can and cannot do, create a new test user with one of the roles assigned to them and log in as them. Do the same for all the roles you want to test until you find the one closest to what you're looking for.
We want some users of one of our SharePoint site to manage permissions on their site but do not want them to give the permission called "Manage Permissions". Because if we do so, the users start assigning the built in permission level “Full Control” to themselves. How can we achieve this?
Please note that the users with the permission level "Manage Permissions" can create and change permission levels on the Web site [Ref: Microsoft]. What we want for them to only be able to create users, groups, and assign certain permissions on the site to those users and groups.
"we want for them ... and assign permissions"
you DO realize that they can just as easily be assigning Full Control to these groups? isn't that what you say you want to AVOID?
manage the permissions for them, and allow them to self manage the GROUP MEMBERS. that way they can add people to the "publishers" group... and net result is that the user has "publish" permissions.
solution 2 can be extrapolated for some very granular needs, but I don't explain how because I wouldn't recommend it.
After reading http://en.wikipedia.org/wiki/Role-based_access_control and seeing the way people are building authorization/access control, this question came to my mind "Why we are checking roles of users when checking if they are permitted to do X rather than checking their permissions?"
This is what I understood, Users have Roles, Roles have permission and this is how a user can have permissions (A user cannot explicitly have permissions assigned to it, it gets its permission by having roles)
And I think it makes sense to check for a permission like "AddUser" when processing a request for adding a user but in .Net library and also in a lot of examples in RBAC we see that they check for Roles. Like they check if the user is in the role of Administrators rather than checking if he/she has the permission "AddUser".
Why? It kind of makes more sense to me to check for permissions.
Can someone please illuminate me here?
Thanks
You are correct - checking for roles in applications instead of permissions is not Role-Based Access Control. Spring security and many other prominent access control mechanisms propagate this security anti-pattern. For correct RBAC usage - perform permission checks in your policy enforcement logic.
If we simplify the RBAC system, RBAC is a method of restricting access to 'some sources or applications or some features of applications' based on rights of users of organization. Here, restrictions can be by means of multiple permissions, those are created by administrator to restrict access, and these permissions collectively represents a role, which will be assigned to user.
You might be partially true for your case :)
But consider a case of complex application, where there are 200 permissions, and administrators need to define few set of permissions to represent specific behavior via role, which will create some complex kind of customization and re presentation of the form for that user.
Here it might be required to check via ‘HasRole(‘SomeRole’)’ method to define exact behavior of user.
So, my answer would be, both methods are equally important in RBAC.
1) HasPermission(‘permissionName’)
2) HasRole(‘roleName’)
A good RBAC solution should provide both these methods. There are such tools available in the market, you can check for them.
My team implemented a UI to assign/revoke permission levels to users on a certain SharePoint list. The UI supplies an "undo" feature to restore the rights the user had before they were changed through our UI.
Now there is a problem if the user had the "Limited Access" permission level: This permission level is removed when you do a change over the UI. When trying to Undo, the permission level should be added again, which leads to a
You cannot grant a user the limited access permission level.
SharePoint grants that permission level automatically when a user gets access to some entity beneath the site. It cannot be granted manually. This permission level is then inherited by all lists in the site. However, after breaking inheritance on a list, I can revoke the right manually, only, I cannot re-grant it afterwards.
So SharePoint treats that permission level quite particularly and I'm wondering how to work around that in our undo feature.
My questions:
Did I get it right that this "limited access" is granted by SharePoint on the site level only, and all the lists beneath only contain that accidentally through inheritance?
Does that permission level have any effect at all on a list, or does it only apply to the site itself?
So, would it be save to just remove it from a list and do not add it anymore when the user clicks "undo", since it has no effect anyway?
I dare to answer my own question just for reference for future readers:
According to Microsoft's article Permission levels and permissions,
The Limited Access permission level
cannot be customized or deleted.
and
(...) Windows SharePoint Services 3.0
automatically assigns this permission
level to users and SharePoint groups
when you grant them access to an
object on your site that requires that
they have access to a higher level
object on which they do not have
permissions. For example, if you grant
users access to an item in a list and
they do not have access to the list
itself, Windows SharePoint Services
3.0 automatically grants them Limited Access on the list, and also the site,
if needed.
In practice this means that:
If you can delete it, that's only because it has been inherited and has no meaning on that certain list.
If later on a user is granted some permissions to a certain list item, so that he needs the Limited Access on the list, SharePoint will take care of adding it again.
Summarized: No concerns to remove and not re-add that access level.
Removing a user with Limited access on the top level site should not actually remove their explicit access on the list or library below (with broken permissions) but MS do say in the above mentioned article:
However, to access a list or library, for example, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted.
This suggests that the user's Limited access should be declared on the site permissions. I think its always best to do a test on your site first before making any assumptions.