I have a section of my content tree which I would like to deny ALL permissions to except for specific roles. This seems like a really obvious task to perform, and yet I don't see an example of it in the Security Administrator's Cookbook and I can't figure out an easy way to do it using the security tools. I must be missing something obvious... ???
Say I have this:
sitecore
-content
-branchA
-branchB
Everything I created in the content tree is readable by extranet\Anonymous by default. But even when I click on the "Require Login" on the security ribbon, all users still have read access, they just have to log in. I want to make branchB readable by ONLY sitecore\SomeRole members. How is this done?
Ok, follow this guideline.
Let's say we have sitecore\SomeRole and a content tree like this:
Home
branchA
itemA1
branchB
itemB1
We'd like to deny acccess to branchB and all its descendants for everyone, except for SomeRole.
First off, in Security Editor select Home node, choose sitecore\Everyone role and set the following permissions:
alt text http://img822.imageshack.us/img822/7172/sitecoreeveryonepermiss.png
Now check the access in AccessViewer - that's what we need:
alt text http://img532.imageshack.us/img532/3512/sitecoreeveryoneaccess.png
Let's allow branchB for SomeRole. Go back to Security Editor and explicitly allow permissions for SomeRole:
alt text http://img80.imageshack.us/img80/120/sitecoresomerolepermiss.png
And check this in AccessViewer again:
alt text http://img27.imageshack.us/img27/9584/sitecoresomeroleaccess.png
Hope this answers your question. Beware that Sitecore versions prior to 6.2.X have an issue: AccessViewer doesn't refresh correctly after permissions are set. Kill aspnetwp (w3wp) to fix this.
It sounds like your problem is that you're allowing the extranet\Anonymous user to have read access too far up in the tree. Remove the access grant at the top level (don't deny it, just remove it) and grant it wherever you really need it (like at branchA).
Related
I have worked with ModX for a while, but can't seem to sort this issue. When I login as the admin in to the manager, the resources list is incomplete with not all documents displaying. I can however locate the files via the 'search' area just above.
I have done the normal, empty cache, flush permissions etc. without any joy. Interesting enough its always the same files, and they are showing in the front end.
Any help welcome on this one!
Update
When I click the blog (which is an articles resource) only the template variables panel is showing, nothing else. Page looks a little broken...
Update 2
If i remove the blog, (articles) the pages show. And... If I move the articles container higher, all resources show.
Are you using multiple contexts? I've noticed this behaviour a few times when drag and dropping folders with nested resources from one context to folder in another context.
Moving them back to the original context made them re-appear.
If you're familiar with MySQL GUIs like phpMyAdmin you could check and search the *modx_site_content* table and maybe correct the value in the resources' parent field manually. As Mark said it might well be a parent gone MIA.
Typically, parents rarely go MIA and by that I mean once every couple years....
Did you set up ACLs or Resource Groups?
Is your manager user a member of those groups?
I have a basic need to protect the integrity of note text in my system; specifically, once a note has been created, no CSR should be able to edit it (higher levels, maybe). Ideally, it should be immutable once created, but I'll allow the CSR that created it to edit it if that's what's necessary; the big deal is that nobody else should have that access.
The basic role permission that enables this is the Write permission of the Note entity. By setting this to "No Access" but still granting access to Create and Append, users can still write new Notes on any Entity they can "Append To" from a form where the notes exist as a subgrid, but they cannot edit any existing Note.
There are, however, two problems with this. First, I lose the "Add New Note" button in the Ribbon. Not a huge deal but it does force the user to add Notes using the inline editor of the subgrid. The bigger deal is that I lose the Attach File button. CSRs still need to be able to attach files, even if they can't edit notes once created.
Is there a way to do what I need?
If it's only GUI protection you're looking for, you might simply set the field to not editable from on load script.
You know, you start creating a distribution called something.good and on it you define a permissions.zcml with something like:
<configure xmlns="http://namespaces.zope.org/zope">
<permission
id="something.good.reset"
title="something.good: reset entries"
/>
</configure>
But then, once the distribution is installed on the server, you realize that the permission is not good enough and has to be completely refactored to something.else.
Uninstalling something.good from plone_quickinstaller does not remove the permission. Going to any security tab within ZMI you can still see it.
I looked around for documentation, browsing code in AccessControl and Products.GenericSetup but couldn't find anything.
Any idea on how to remove it?
Ok, so Plone is easy, don't mind what others may tell you.
So, you (actually I) want to remove a permission definition? Just do it!
So the list of things to check to properly remove a permission are:
remove the permission from permissions.zcml
if there are no permissions left remove any reference to that file (maybe on your configure.zcml)
remove all references to the permission on profiles/default/rolemap.xml
scan all your configure.zcml or python files (if using grok-like permissions) to references to that permission
And that's it!
Once you restart your instance the permission will no longer show up on ZMI's Security tab.
Seems that permissions are created on-the-fly at startup time? Seems so to me. Prove me wrong though!
in a List i have one 'Status' field that should be accessible to only Owners and to the Viewers/Readers it should not be accessible. Do anybody can guide me how to do this.
Well, you can, your view still is visible if the users know how to reach the default views of your list, if its not a security issue, you can use this:
Open your All Items View (/Lists/MyList/AllItems.aspx)
Edit the Page
Add the same List as a WebPart, twice
Delete the original webpart (the one with the Change View drop down)
Edit your WebParts and configure your views
In the Toolpart, on the Advanced [+] set Audience Targetting to your desired Groups
Done!
Either that or you can create a workflow that copies the item to a new list with its metadata, but without that specific column and only give the viewers rights to see that list.
If the question is one of security (it usually is, else just use a view), you can't lock down specific columns. You can find techniques to hide them, but then you're just plugging holes.
The workflow approach recommended by KoenVosters is probably the only secured way I can think of delivering this without coding.
This is not possible out of the box, but I came across this tool that will help to archive this with ease
Currently after I create a release branch, but when we have some time before we release, I sometimes open the entire branch for edit and then lock all files in order to prevent anybody from modifying anything during "code-freeze" period in the release branch.
Is there a better way? Doing it my current way seems possibly like an incorrect use of the lock feature, is there a better way to keep somebody from checking in code without using branches. I though of P4 protect but I am not the admin on this perforce instance, and also dealing with the protect file at potentially 100s of lines would get cumbersome as well.
Any ideas?
I'm doing this all the time as a builds engineer. I use 'p4 protect' to restrict everyone's access to the trees to read-only:
super group everyone * -//depot/project/branch/...
read group everyone * //depot/project/branch/...
super user me * //depot/project/branch/...
The first line closes all permissions for all users to the branch (assuming that the group 'everyone' is defined properly.)
The second line re-establishes read permissions for everyone.
The last line re-establishes all permissions to just me.
The way to do this in modern Perforce is to use streams -- named branches that update in place on your local system, and can have permissions applied to encourage you to do the right thing when merging and copying between streams.
You can optionally restrict a stream so only the stream owner can check in (and you can lock the stream so no one but the owner can edit its properties). See http://www.perforce.com/perforce/doc.current/manuals/p4guide/chapter.codelines.html#codelines.streams
p4 protect is definitely the better way to go - it's what it is there for. I would strongly recommend you put all your users into groups, and only ever use groups in your protections table - much easier to manage.
You can protect at any level of granularity you like, so is not unwieldy. Note also that the 2008.1 server release has a new protect feature that allows you to specify what you can do in a slightly different way. Change note:
#152278 **
'p4 protect' now allows specification of permission 'rights'.
Previously, 'p4 protect' only allowed using permission levels
which include the specified access (ie 'read') and also all
of its lesser permissions (ie 'read' = 'read' + 'list').
Permission rights make it possible to deny individual rights
without having to re-grant lesser rights. The new
permission rights are '=read', '=branch', '=open',
and '=write'. This functionality was previously undocumented,
and is now fully supported for 2008.1
If you really have an issue with having to be an admin to lock & unlock this, then you should take a look at the "group owner" feature introduced in 2007.3. This will let a non-super user to be able to add & remove people from a group. So combine that with the protections table. I.e. get site admin to set up the protections table, and restrict rights to a group named "Rel 1.0 Authorised", and make you the group owner. You can then add and remove users (or subgroups) from that group to control access.
The trigger option is a possibility, but you still need to be an admin to set up the trigger in the first place. You could also affect performance of all submissions, which is something to look out for. But the main issue with triggers is that you would be using them to emulate a built in feature designed for that purpose - i.e. protections table. And, if you wanted to be safe, you would still need to find some way of preventing anyone else modifying the reference file. It just seems like a lot of work to emulate an existing feature.
As a slight addition to one of the other answers. First set up a group "everyone" which has all users in it. Then add this to p4 protect
write group everyone * -//depot/project/1.0/...
read group everyone * //depot/project/1.0/...
write group 1.0 * //depot/project/1.0/...
This will allow you to create a group "1.0" into which you can add any users who are allowed write access.
If you are using server 2008.1 you can do this.
=write group everyone * -//depot/project/1.0/...
write group 1.0 * //depot/project/1.0/...
The first line removes only the write access ( not read and list ) from the group everyone.
P4 protect is probably the right answer for most people as explained in other answers.
However in my organization I can't be the admin so way of doing this is to have a trigger script in perforce that reads a text file that non-admins have write access to and check whether branch appears on the list.
This way admin access like p4 protect would need is not needed.