Attached is a tar file containing ALPHA level code (experimentation) that allows for multiple Access Control modules to be used together. It maintains the current API so should be compatible with existing access control modules. The code is based on Drupal 4.6.1. Please read the readme.txt and referenced documentation.

Please only use this ONLY if you have an experimental site/database available. Although the code has not burned my house down yet, testing has been very limited. This release is to test the basic theory and my approach to solving this issue. And to see if such a solution has value to anyone but me. MUCH more work is needed to bring this to production level code, including implementing an improved API.

I have research level code that improves the performance considerably, there are obvious bottlenecks in the current implementation, but I wanted to get this out before it featured creep into next year.

Thanks

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bomarmonk’s picture

I may give this a test run! Thanks for your efforts!

robb’s picture

I have received some problem reports for the version posted. I am working on a fix today (Thursday), should be ready by late afternoon UTC -7.

bomarmonk’s picture

Have you come up with a fixed version? I am definitely keeping my eye on this.

robb’s picture

Yes, it is now at Alpha6! This is the last scheduled Alpha before Beta.

The performance has been increased substantially. I now see < 10% performance hit for complex combinations and no performance hit for simple (or default) operations. Individual nodes are retrieved at less than 1% difference in performance. Of course your millage may vary, I am using a 5,000 node Drupal test database. Most of the gain has come from a query optimizer that chooses when to create temporary tables, how many joins to use and so on.

There is now an audit page that shows why access was granted or denied to a specific user and node. A sandbox is included to test ACTs without having to actually commit to them. It makes it a lot easier to track down any problems.

Functions were just added that allow an ACT to make decisions not only via an access control module but now also by the Roles a user is in, not in, etc.

After a rather embarrassing first release I am now operating a limited Alpha release. If you would like to be on the list please send me a message and I will route the latest version to you. I would love to have a couple more testers try this before it goes to Beta.

robb’s picture

FileSize
88.11 KB

Beta1 Release of node_access!

Supports any number of node-access type modules under Administration control. This means that OG, TA, NodePerm, etc. can be combined in wonderful new ways.

New features since the last release:

  • Should install easier
  • Many performance improvements.
  • Audit tab in Access control added. Includes syntax checking of ACT and the ability to see who/what/why access was denied or granted
  • Functions in ACT are available, the default ones allow for checking Role memberships. Modules can add more via hooks

See the readme.txt for general installation, tutorial.txt for some initial help and the node_access control panels.

  • Admin >> Settings >> node_access
  • Admin >> Access control >> Audit

The module is ready for general testing and feedback!

Thanks to my Alpha testers who provided support and feedback during development.

robb’s picture

FileSize
88.13 KB

Updated!

The last versions still had development debugging enabled leading to a lot of diagnostic messages. This version fixes that.

robertDouglass’s picture

keep up the good work. I look forward to testing this.

robb’s picture

Thanks, right now I am waiting for feedback to see what's needs to be done next. The module is being used by a couple of early adopters and is working well for them.

wedge’s picture

I'm having some problems when running this with PostgreSQL (8.0.3). Queries like this:
SELECT DISTINCT(n.nid), n.sticky, n.created FROM node n INNER JOIN node_access na ON n.nid = na.nid WHERE ((1)) AND n.promote = 1 AND n.status = 1 ORDER BY n.sticky DESC, n.created DESC LIMIT 10 OFFSET 0 are giving me errors:
ERROR: argument of AND must be type boolean, not type integer.

Any suggestions? Many thanks for the excellent documentation of the module btw. Keep up the good work.

robb’s picture

I was afraid of that. The module was not tested with PostgreSQL, per the readme file. I have made some corrections to get it closer and will be setting up a full PostgreSQL test server in the next week. If you would like to test the newest version, it should solve your specific problem, send me a private message and I will add you to the Alpha test group.

By the way, the SQL example you provided indicates that your ACT resolved to a constant TRUE value. Was that an experiment or does it indicate another problem I should be looking at?

Thanks for testing the module and your kind words.

robb’s picture

FileSize
93.92 KB

Attached is the latest version of node_access. It now supports adding functions via modules and some other advanced features. This module is currently in bug-fix only mode.

drofnar’s picture

Category: feature » support

Hi Robb, Is beta v2 the latest version? and will this be incorporated as a full drupal update, it sounds really useful/improtant functionality, with 4.7 coming out soon, unless there is good reason wouldnt this be worth including in the 4.7 release?

shouchen’s picture

Is any work needed to make this work with upcoming Drupal 4.7? Is Beta2 still the latest version?
Thanks.

sethcohn’s picture

Category: support » feature
Status: Active » Needs review

Seems to work correctly with 4.6 code... OG and TA both installed and functioning.

+1

venkat-rk’s picture

Don't have the faintest idea of which module to use this patch against. I see it is a 'drupal' project issue, though.

robb’s picture

This project is based on Drupal 4.6.3 and consists of a patch against node.module (or use the included pre-patched node.module) and multiple support modules. The README, INSTALL and TUTORIAL files should get you started. If not drop me a message. Using node_access requires some intermediate knowledge about creating appropriate boolean logic statements but the tutorial does provide a number of examples.

I hope that answers your question.

moshe weitzman’s picture

Status: Needs review » Needs work

this approach in this patch is simply too complex for core drupal.

robb’s picture

I agree it is complex, but then security can be a complex thing. I also think that it is too much to place into the core. I would prefer that node_access functionality could be handled entirely within a module. When I get a chance to work on 4.7 I have some design ideas that would allow this module to be activated like any other and tie into new hooks in the node.module. I have learned a lot about Drupal since I wrote this module (my first module for Drupal) so I expect a number of improvements will be made when I upgrade it to work with Drupal 4.7.

The upside is that the module does allow the admin to use security that is specific to their needs. In my current test version my security options exceed those I had in Plone and are easier to maintain! Keeping t Drupal's philosophy of small modules to do specific things I can easily add/remove/configure node_access modules to provide almost any functionality I desire.

I considered a new security API but everything I came up with seemed to eliminate or reduce the ability to mix and match separate node_access modules together.

Any suggestions are welcome!

chx’s picture

Slightly off topic: permissions are not security in my book.

bomarmonk’s picture

Version: 4.6.1 » 4.6.5

Rob, I get a strange error when trying to log onto my site which is running node_access. I only get this error when I am at another computer, other than my home computer. Both computers are running the same operating system and the same version of Internet Explorer. It may be that my account is still logged in from the other computer? I don't know. Anyway, here is the error message, whcih may have something to do with core access, but I thought the expermental node_access module was more of a suspect:

WARNING: A request for MATRIX failed. There is no current user. Please call _node_access_set_matrix() first.

Weird. Other than this one odd occurance (which happens every time I try logging in from this particular machine), the node_access module has operated flawlessly (well, there may be an issue with workspace and simple_access/nodeperm_role-- but I've already discussed that elsewhere).

Anyway, any suggestions for my configuration would be appreciated. I'm running node_access, taxonomy_access, simple_access, and workspace. This is all in Drupal 4.6.5.

robb’s picture

Please try the latest version on my experimental Drupal site. The latest version has some bug fixes that may help you.

http://www.lab.canfield.com/projects

There are some other projects there that may also be of interest to you. I will post them to Drupal once CVS access is granted. Let me know if you still get the failure.

dkruglyak’s picture

The functionality works great so far, but I noticed significant performance hit. My node_access table has ~10K rows and the only index is the primary key.

What kind of queries does this module run? What extra indices could speed it up?

dkruglyak’s picture

Oops, looks like there is a major problem. OG supports only one operation (view), which as far as I can see translates into visibility of a node to the current user.

This does not take into account the difference between node/user group membership and node/group visibility settings. A node could belong to a group, yet made publically visible by checking "public" box by author or admin (see "Visibility of posts" in OG settings).

We are working on a setup where group members author posts that are made available publically. This makes it impossible to control the editing rights, unless there is another operator (e.g. og.member) to check group membership instead of visibility setting.

This operator needs to be added.

robb’s picture

regarding performance hit:

My module works within the current Drupal node_access API. This API was never intended to operate with multiple node access modules! I force it to do so by creating a rather complex query, or serious of queries that perform the AND, OR operations as defined by the ACT. This can be slow depending on the operations being performed. To help you optimize your database I need to know some more details:

1. Your ACT that is slowing you down
2. The number of nodes, not node_access, rows
3. Your SQL server.
4. If possible some benchmarks of a normal (no ACT) and ACT related query (Very Helpful!)
5. If you have the Devel module that list of queries performed applicable to the ACT

I realize this is a lot to ask, but node access is very tricky and makes numerous optimizations based on the above, With these I may be able to offer some suggestions but limitations in Drupal, actually in node access modules, limit what can be done.

For 4.7 I am working on a new API that modules can take advantage of that should offer significant performance gains. But more experiments are needed before I can release this, and modules must be patched to take advantage of the new capabilities.

robb’s picture

Re: OG

I am limited to what Organic groups supports via the Drupal node_access API. I am not sure I can resolve this problem without patching organic groups. I will look into this closer as I prepare node_access for 4.7 and see what can be done, but I will need some time.

Until then you may want to try my secure_path module. It has a more general control mechanism than Organic Groups and should be able to work as a complement to it. secure_path is EXPERIMENTAL and exists only on my experimental site, http://www.labcanfield.com/projects. It uses a hierarchy permissions setting as well as a Public flag setting. I use it to create private Intranet and Public Internet content all on one site. I also use it with my workflow actions to create a very powerful Create, Reject, Submit, Edit, Publish workflow.

Robb

dkruglyak’s picture

FileSize
33.64 KB

RE: node_access performance

Let me answer the questions first:

1. It is slow enough with default ACTs (none entered)
2. node rows: 3,000, node_access: 10,000
3. MySQL 4.1 on Linux
4. With node_access disabled these hard queries do not show up and the setup is much faster
5. A screenshot of devel query log dump is attached (frontpage after user logs in)

The problem query is the bottom of the log, right after user logs in. I think it may be CONCAT that is wreaking havoc. Perhaps it could be broken up into a few more columns?

dkruglyak’s picture

RE: organic groups

Are you really sure you need to modify something in OG module? It is already supposed to expose the API for verifying whether a user is a member of a group. You can wrap it into node_access under og.member syntax, while og.view will remain as is...

Will try secure path too.

jun’s picture

Hi there,

I'm quite new to drupal, andI'm not sure about where to post this, since I had a problem with the combination of node_access and og. I will post it here hoping that the interested parties will get it and orient me as to where it might have to be duplicated (the og issues?)

my setup is:
drupal 4.6.5
the node_access found in this thread
og 45 (although it seems that the problematic code, see further down, is still present in the latest og 56)
taxonomy_access 1.47.2.11 (for information since this doesn't appear to be linked to the problem)

I can't quite understand why no one seems to have reported this issue,since I don't think I'm doing something particularly off the beaten path with node_access and og... So I hope someone will be able to reproduce it.,,

When trying to see the details of a group with an anonymous user I would get

PHP Fatal error:  Unknown column &#039;na.gid&#039; in &#039;where clause&#039;
query: SELECT COUNT(*) FROM node n  INNER JOIN _node_access_m na ON na.nid = n.nid LEFT JOIN _node_access1 ON _node_access1.nid = na.nid LEFT JOIN _node_access2 ON _node_access2.nid = na.nid LEFT JOIN node_comment_statistics l ON n.nid = l.nid INNER JOIN users u ON n.uid = u.uid WHERE  (n.language =&#039;en&#039; OR n.language = &#039;&#039;) AND (( (_node_access1.grant_view &gt; 0 )  AND  (_node_access2.grant_view &gt; 0 ) )) AND (na.gid = 6 AND na.realm = &#039;og_group&#039;) AND  n.status=1 AND  n.type IN (&#039;audio&#039;)  in /var/www/core/includes/database.mysql.inc on line 66

When logged in as admin, there was no issue.

I traced back the problem to the following code in og:

function og_db_rewrite_sql($sql, $primary_table, $primary_field,  $args) {
  if (is_numeric($args['og_nid'])) {
    // we add this JOIN for node admins and when node access is disabled because node_rewrite_sql() adds it for everyone else
    if (user_access('administer nodes') || node_access_view_all_nodes()) {
      $query['join'] = 'INNER JOIN {node_access} na ON n.nid = na.nid'; 
    }
    $query['where'] = '(nag.gid = '. $args['og_nid']. " AND nag.realm = 'og_group')"; 
    return $query;
  }
}

as the comment states, and if I understand correctly, this code assumes that node_rewrite_sql() has a INNER JOIN node_acces na ON n.nid = na.nid.

The problem however is that when the node_access module found here is installed, this assumption seem to no longer be valid, which causes the fatal error above.

My workaround has been to simply remove the if statement (I guess it would be cleaner to test for the node_access module's presence (I'm not sure how to do that). I also had to change the alias from na to something else because of duplicate aliases. So now my og.module, has :

function og_db_rewrite_sql($sql, $primary_table, $primary_field,  $args) {
  if (is_numeric($args['og_nid'])) {
    // we add this JOIN for node admins and when node access is disabled because node_rewrite_sql() adds it for everyone else
    //if (user_access('administer nodes') || node_access_view_all_nodes()) {
      $query['join'] = 'INNER JOIN {node_access} nag ON n.nid = nag.nid'; 
    //}
    $query['where'] = '(nag.gid = '. $args['og_nid']. " AND nag.realm = 'og_group')"; 
    return $query;
  }
}

Not very pretty but it seems to work so far... I'll follow up if it seems to have broken something else...

The problem is also linked to node_access, as when it is buiding it's temporary tables (in my case with _node_access_build_complex) it doesn't include the gid in the selected columns. Another fix might have been to do just that (include the gid in the temporary tables) but it didn't felt like the right thing to do...

Anyhow, I'd loke to say that I'm so impressed with the code you guys created, for og and node_access. It feels good to stand on the shoulders of giants ;-) So thanks!

Peace,

Jun.

magico’s picture

Version: 4.6.5 » x.y.z

We really need to unify one system of node access control.

Tobias Maier’s picture

i think there was something like this committed to drupal head:
http://drupal.org/cvs?commit=37640
http://drupal.org/node/75395

eaton’s picture

Status: Needs work » Closed (fixed)

A unified node access system was, in fact, committed to HEAD. It's designed to support precisely the scenerios described -- multiple access modules working side by side.

moshe weitzman’s picture

Status: Closed (fixed) » Closed (duplicate)

and with that inane remark, we close this issue as duplicate. see http://drupal.org/node/71420