On Drupal's Node Access Control Scheme

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 powered by Disqus