I’ve already discussed my issues with the current node access, and even presented a possible solution. The nice thing about that solution is that it can work as a contrib module and live in its own little universe; other contrib modules can rely on it, and things can work, and I believe it can work well.

But it doesn’t address another issue, and that issue is fine-tuning access control. There are times when role-based access control just doesn’t work well. When that happens, the only solution ends up being something along the lines of access control lists. The first thing that came to mind when ACLs were mentioned to me was “OH DEAR GOD NO!!!” but as I thought about it, it started to seem to work a little bit better for me.

First, if you reacted the same way I initially did, take a deep breath and hear me out. I probably won’t convert you right away, but think about the process.

As I’ve mentioned, there are times when role-based access control just isn’t fine tunable. Sites that are very…well, organic…might have a lot of different working groups, and the ACL works much better. Add someone to a group, and voila, that group list can now give them access to things that they need to.

And here are a couple of other places it’s useful: Forum moderators. With ACLs, each forum can have a unique list of moderators, independent of everything else, simply by attaching an ACL to the forum moderation functions.

Blog posters could have privacy similar to LiveJournal, by enabling ‘friends’ lists, and posting with ACLs.

Multi-user blogs can be more easily possible, by using an ACL to determine who can add entries to the blog.

Use your imagination, there are a lot of areas where the ACL can become useful. Of course, the reason for the initial reaction is that ACLs are notoriously difficult to maintain. Or are they?

First, you have to have different kinds of ACLs:

1. Role-based ACLs. Every role in the system automatically creates an ACL, and this ACL is easily accessed through that means. These ACLs would emulate current functionality.
2. Administrative ACLs. Special lists created by administrators that are only accessible by administrators.
3. User defined ACLs. Each user could have some ACLs. Think of these as livejournal friend groups.
4. Module defined ACLs. The above mentioned forum module would create special ACLs; this would ease the maintenance difficulties of creating an ACL for every forum.

Second, and this is the rough part — node_access would have to be completely changed, because right now it only knows about the role based authentication. Instead, it would want db_rewrite_sql to modify the join query for the ACL.

I believe if set up roughly like this, the ACL query stuff would work roughly the same or perhaps better than currently:

CREATE TABLE acl (
  aclid int(10),
  name varchar(128),
  type varchar(16),
);

CREATE TABLE acl_user (
  aclid int(10),
  uid int(10),
);

CREATE TABLE acl_node(
  aclid int(10),
  nid int(10),
  type varchar(16), -- 'access', 'update', 'create', 'delete', 'module-specific', etc.
);

Now, the query is a ton easier if it’s limited to 1 ACL per node per type, or at least for the ‘access’ type which is what the db_rewrite_sql code cares about. The only real place I can see where multiple ACLs on a single node is if an admin wants multiple roles to get read access. In that case, it might be worth creating an aggregation ACL, wherein an ACL can be defined as containing some group of roles. At this point I’m not sure which direction to go: what’s more important, streamlininig the access control query or making it easier to assign multiple ACLs to a node.

In any case, the query ends up adding the following elements if it’s just one acl per node:

• LEFT JOIN acl_node an ON n.nid = an.nid AND an.type = ‘%s’ LEFT JOIN acl_user au ON au.aclid = an.aclid AND an.uid = %d — %s => ‘access’ %d => $user->uid
• WHERE (an.aclid IS NULL OR an.uid IS NOT NULL)

There may well be better ways to modify the query as well. If you allow multiple ACLs per node, then you have to add a DISTINCT to the nid which is something I occasionally fight with in the current node_access system, though we seem to have mostly ironed the bugs out of it, so maybe it’s not a big deal. Note that this does handle the case where if there is no ACL attached, then view access there works just fine.

There’d need to be a hook_user that ensured that when a user was edited, that user appeared in the proper role-based lists. We probably don’t want an ‘authenticated user’ access list, so some other means of enforcing content only for logged in users would need to be applied as well. That’s a weakness I’m not yet sure how to address. Likewise, there are probably other options that would be nice, such as being able to add ‘node owner’ as an option.

Obviously, this is not a 4.7 feature, but a 4.8 feature at best, and if that happens, hoo boy is it a major change. Perhaps making it an optional change: “role-based access control or ACL-based access control” but having to write code for both systems would…verily…suck.

I’m eager to hear any comments anyone has on this.