How to secure a page so that only users in a specific role may edit it

Topics: Administration
Jun 3, 2013 at 4:22 PM
I'm trying to secure a page whose content will be owned by a specific group of people. These people should only have rights to this particular page, and no others.

I enabled the content permissions module, but I cannot seem to configure it such that a specific role can only edit that particular page and no other.

Is there a walkthrough available on how to configure this? I'm assuming that I'm doing something stupid. :)
Jun 3, 2013 at 6:59 PM
I don't know what your familiarity is with Orchard, so this may seem obvious, but have you added the Content Permissions part to the Page type?
Jun 3, 2013 at 7:29 PM
I've seen it, and I've enabled it and added the Content Permissions part to the Page Content Type, but I can't seem to fiddle the configuration such that only users in a specific role have access to edit a specific page.
Jun 3, 2013 at 7:53 PM
I just messed around with some of the settings myself, and I see what you mean. I couldn't make it work just yet, either.
Jun 3, 2013 at 10:15 PM
I've gotten this figured out. Looking through the source, the ContentPermissions module expects the user to have a *Content permission - i.e. Edit Content for Others and friends. Granting the role the Edit Content for Others (I had been granting the role Edit Pages) allows the authorization rules to apply properly, but has the rather unpleasant side effect of granting access to any page not specifically assigned item-level permissions. The result is a solution that's permissive by default, which is sort of the opposite way you want security to work.

Of course, it's entirely possible I'm missing something; if so, feel free to beat me with a smelly halibut.

I'm investigating possible fixes for this now; would folks consider this a bug, and if so, where should I file it?
Jun 4, 2013 at 12:13 AM
Edited Jun 4, 2013 at 12:23 AM
Looking at this, it would seem that the basic issue is that AdminController's Edit action always checks for EditContent permission, which works today since EditContent implies EditOwnContent. During the permission check, it looks like ownership of a content item is basically a special case, meaning if you own the content item, the permission check is for EditContent, but we'll adjust the CheckAccessContext and set the permission demanded to EditOwnContent.

A much simpler design (and perhaps flawed? looking for feedback) would be to allow roles to directly own content. Then the ownership question becomes, are you listed as an owner of the content item or do you belong to a role that owns the content item.

The existing mechanism for doing page-level security is pretty rough; if you wanted to grant a group of individuals rights to just a selected set of pages / content type instances, you'd need to flip a lot of knobs on each page/ content type instances, and make sure that every page / content type instance had content-item permissions granted, otherwise the folks granted specific rights to selected pages / content type instances would also get rights to all pages / content type instances that didn't have item-level permissions granted.

I've got a rough outline of a patch for this pulled together; modify the OwnerEditorDriver to allow specifying a role, and modifying the HasOwnership implementation of the Orchard.Core.Contents.Security.AuthorizationEventHandler to recognize user role membership as a type of ownership.

The only thing that bothers me is role-name / user-name collision, but so long as user's are matched first, the authorization check should always "do the right thing" in terms of filtering on the most-specific permissions.

What do you guys think? Would a patch like this ever be accepted? Worst idea ever? Looking for feedback. Please be gentle. :)
Jun 4, 2013 at 12:57 AM
Would not be accepted :/ The logic is too weak, as the owner has always be intended for a user and no you could use it to specify a role. Your best approach right now would be to use your own module to apply a custom AuthorizationEventHandler, like it's done in the Content Permission module.

I would gladly spend more time on this issue and see if there is a flaw a if something can be done, be right now I don't have enough time, 1.7 is to be released soon, and the conference is next week ...
Jun 4, 2013 at 1:59 AM
Thanks for the feedback! What portion of the logic is weak? Overloading the owner field and using a role name there?