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!
Related
I created an admin section for a website of mine using PHPMaker - as I usually do. The website is made from scratch, no wordpress or anything else involved.
In some apparently "innocent" tables, if I try to edit them, I get a 403 error. It never happened, and I used PHP maker for at least 15 websites of mine, so I am puzzled.
It happens only on 2 tables out of 15, and as said, they are fairly innocent. Nothing fancy compared to the other ones.
This is what I've tried:
there was no .htaccess file in the admin directory, so I also tried to insert an empty one
clearing the cache
visiting the page in private mode
all file/directory permissions are ok
regenerating the project and uploading it again, to a different directory
What else can/should I check?
There is a .htaccess file on the root directory of the server to handle some "pretty url", but it should not matter since the admin section is under a specific directory. Or should it matter?
Thank you
At least, I found the problem: every time I was trying to insert an iframe or a script, somewhere somehow somebody (...) was parsing it and it was blocking it for - I guess - security issues, so I let the user to insert the script without the <script> tags, added later in PHP simply with:
print "<script>$readFromDB</script>";
In each insert action, PHPMaker will parse the word
<script
and converted to
<s<x>cript
You have either get the inserted rowid and update the value again OR each time you have to remove the '< x >' to view the value correctly.
Take a look at my answer here: PHPMaker issue
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?
Is there a way to check what is the target of a link, using NSIS ?
[ I want to check and update links on desktop, but I have a hard time checking if they belong to my application, because the name may contain a space or something, so it may not be identical...
I also want to delete links that are no longer used, that point to my folder.
So... I would like to look at the target, but can't fins anything that gives it to me. ]
You could try the ShellLink plugin or call the IShellLink+IPersistFile COM interfaces directly with the system plugin but normally a uninstaller/updater will only deal with shortcuts it created and not things the user might have created/renamed...
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).
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.