Rob Thorne wrote:
I'm writing a module for 4.7 that needs to control access to nodes that are only viewable by users who are approved via an external module. To determine if a node is viewable, I need to check the user *and* the node id. This would work, except for a design decision that was made "for performance". Here's what it says in the docs, in the article about "Node access rights" (http://api.drupal.org/api/HEAD/group/node_access):
In node listings, the process above is followed except that hook_access <http://api.drupal.org/api/HEAD/function/hook_access>() is not called on each node for performance reasons and for proper functioning of the pager system. When adding a node listing to your module, be sure to use db_rewrite_sql <http://api.drupal.org/api/HEAD/function/db_rewrite_sql>() to add the appropriate clauses to your query for access checks.
In other words, even if you set up your hook_access to prohibit viewing of your content, Drupal 4.7 *will display your private content to an anonymous user*. Once your private node gets added to the list, there are no further checks to your hook access to determine if your node is safe to display. I don't see any way that hook_db_rewrite_sql can be used for this purpose, since there is no simple relationship between the current user and whether a node should be viewable, short of doing one of the following things:
* I could use a IN () clause to list every node id of the given type that the given user is allowed to see. This may work in my current situation, but there can easily be *thousands* of these in some applications. So this is not a general solution. * I could manipulate the node_access table *on the fly* each time a user with some access to the content type. * I could somehow hack the node to hide itself by not displaying any sensitive content in hook_view, and theming it to be hidden via CSS.
<rant> IMNHO, this is complete insane. </rant> Is the ACL stuff I wrote in the na_arbitrator insufficient for this?