Jul
14
(2006)
On Drupal’s Node Access Control Scheme
Filed under: Uncategorized. Tags: drupal.
Drupal is aimed at making it easy to publish and manage a website right out of the box. Its main goal is getting content online, without providing many restrictions on who gets to see it (you can turn off guest access to all content, or for some specific content types, but there isn’t a native “audience” defined for content).
There are a whole bunch of really cool modules that add this additional functionality. Organig Groups lets users define their own groups on the fly, making it easy to discover content published to a group. Simple Access lets you define which roles get to see/edit/delete content. Taxonomy Access lets you define which roles get to see content tagged in a specified taxonomy/keyword. Etc… The list goes on and on. Lots of great access control modules, each doing different things to manage access to content according to various workflows and scenarios.
But, currently, they are all incompatible with each other. Want to use Organic Groups to let users post blog entries into their own little workgroups? Great. But don’t use Simple Access to define editing access to the “static” pages of the site. And don’t use Taxonomy Access either. Or vice versa.
Because the access control modules all seem to whitelist - if any of the installed/enabled modules says a user can see a piece of content, they can see it - no matter what the other modules say. It might be safer for modules to blacklist instead - if any module says “no!” then it’s not accessible.
Simple Access could be saying “only Admins can see it” - but if it’s also published into an Organic Group that someone belongs to, they get to see it even if they’re not an Admin.
And, if Organic Groups says “only peopie in the ‘my favorite workgroup’ group can see it (not public, audience = ‘my favorite workgroup’)”, then Simple Access can say “hey! But everyone’s allowed to read it according to my settings, so have at’er!”
It’s a little frustrating, having to say to a professor “yeah - we can make sure that only specified members can read your medical research progress pages, but that means all forums on the site are wide open to the public. Or, we could do the opposite, if you don’t mind your confidential medical research open to the public…”
There’s some hope, in the form of Node Access Arbitrator. It’s an “experimental” module, attempting to define/offer an API for these various access control modules to play nicely together, without tripping over each other.
But, not many access control modules have been made compatible with NA-Arbitrator. Perhaps because NA-Arbitrator isn’t a core module, nor is it flagged as a recommended one.
So - how about taking NA-Arbitrator either into Core, or marking it as being “supercool” - as Views and CCK have been - so people will have the impetus to update their access control modules to use a unified API?
If the API isn’t complete, or is off the mark, it makes sense to focus development on a single, sustainable central concept of node access arbitration, rather than just leaving the various modules to duke it out…
If there’s an “official” node access strategy in the works, I’d love to hear about it. Dries? Merlin?
Comments
8 Responses to “On Drupal’s Node Access Control Scheme”
Leave a Reply
You must be logged in to post a comment.
Boris made a comment, but it got stuck somewhere it Cocomment land. I’ve disabled that module in case it’s gumming things up, and here’s Boris’ comment:
Usually you really only do need only one of the modules. For example, Organic Groups can be installed and made to exclude book pages, and then you only give book editing permissions to a particular role.
So the short answer is, the node access API is there so different implementations can exist. I, personally, do not fully trust anything other than organic groups.
Your description of whitelisting/blacklisting is a simplified description of what is actually happening at the code level…it is much easier to say than to implement securely, robustly, and in a scalable way.
AFAIK, there is no one actively working on NA Arbitrator. The “strategy” comes from whomever puts time (well, code and patches) into development. So…if you’ve got an itch to scratch, start submitting patches and start the discussion.
Boris - we tried using Organic Groups for everything, but for many things the simplicity of Simple Access was what the clients needed.
I’ll take another look at the latest version of OG, with the extra modules (like forum groups…) and see if I can replicate everything just using OG.
This is one of those areas where almost every single client/professor/user we work with steps back, scratches their head, and says some variation of “you mean Drupal doesn’t let me pick the audience for a page?”
In our case, we’ve got a bunch of nodes as “Page” nodes, some of which are restricted by Simple Access. We also have blogs and forums, which may be more appropriate using Organic Groups to define access and group views.
the arbitrator really is the futue. i am waiting for someone to pay a bit in order to port og to it. thats not trivial.
moshe - true. I’m still mulling over my access control list module. On the one hand, it’d be straight forward to build it as a standalone module. But then I’d have the conflict issue when used with other acces control modules. As an NA-Arbitrator module, at least it could play nicely with other NA-Arbitrator modules…
Also, I just downloaded the latest suite of OG modules from CVS, and with access control enabled for OG (and only OG), it is close to what I need for at least one project.
Actually, I intend to take the arbitrator and submit it as a patch for 4.8.
My biggest issue is that I'm not happy with the 'priority' feature, but at the moment it's the best we've got. The guy who was doing the node_access.module, now renamed na_multi.module was working on making something a little more flexible, but that seems a long way off and difficult to convince people of.
The arbitrator, on the other hand, may make it in, I just need to do it. And explain it. The explanation actually is harder than the code. :P
D'Arcy, when I get back from Germany, I would love to have a voice chat about this…..what if you actually think of organic groups as access control…that is, you might not even *use* the actual group home page.
(this pretty much just goes to show how much I trust OG)
But in general, being able to do per-post, per-user access control would be a Good Thing™ in many cases.
Boris - absolutely. Let me know when you’re back on the left side of The Pond…
Access control to contacts is probably the most difficult piece of the CiviNode code base, and needs a bit of discussion. Perhaps the best way to start is with the basic scheme, and then a discussion of how this is different from what CiviCRM already does, and how it differs from different schemes used or under discussion for Drupal.