Overriding node_db_rewrite_sql()
Currently, I patch the node.module's node_db_rewrite_sql() function. What I would like to do is take this functionality and put it into a separate custom module so that I don't have to patch the core module. I was advised to take the code, place it in my custom module, and weight my custom module heavier than the node module. Tried that, but I'm getting some serious errors. Here is essentially what I'm trying: Taking the same node_db_rewrite_sql() code and placing it in my custom module: function og_user_roles_db_rewrite_sql($query, $primary_table, $primary_field) { if ($primary_field == 'nid' && !node_access_view_all_nodes()) { $return['join'] = og_user_roles_node_access_join_sql($primary_table); $return['where'] = og_user_roles_node_access_where_sql(); $return['distinct'] = 1; return $return; } } function og_user_roles_node_access_join_sql($node_alias = 'n', $node_access_alias = 'naa') { if (user_access('administer nodes')) { return ''; } $return = 'INNER JOIN {node_access} '. $node_access_alias .' ON '. $node_access_alias .'.nid = '. $node_alias .'.nid '; ... my customizations follow ... This actually appears to work for normal authenticated users. However, user #1 is getting ALL nodes listed in every view everywhere. The second problem I've run into is that for certain users, they now get "access denied" error when trying to access content they should have access to. It's like my permissions table got screwed up somehow, but I don't know how to fix it. Help, please! -ron -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com
This actually appears to work for normal authenticated users. However, user #1 is getting ALL nodes listed in every view everywhere.
user #1 has unlimited access to everything. There are no restrictions in effect whatsoever. db_rewrite_sql is iirc not used for uid #1. Konstantin Käfer — http://kkaefer.com/
Konstantin Käfer wrote:
user #1 has unlimited access to everything. There are no restrictions in effect whatsoever. db_rewrite_sql is iirc not used for uid #1.
What I mean is that when I add my custom hook_db_rewrite_sql, user #1 sees all nodes regardless of the view. If the view is for a group, user number #1 sees all nodes in the system, whether they are in a group or not. I guess my question is: Why do I have this behaviour when I add the node_db_rewrite code to my custom module since I don't have this problem with the default node_db_rewrite_sql?
Konstantin Käfer — http://kkaefer.com/
__________ NOD32 2421 (20070725) Information __________
This message was checked by NOD32 antivirus system. http://www.eset.com
-- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com
user #1 sees all
Yup. user 1 has all possible rights, there is a special check for it so that every kind of access check is TRUE for this user. In this case, node administrators can see all nodes and because user 1 has every right, she is also a node admin.
Ron-- User 1 is a special "super admin" role that does not follow normal access control rules, including node access. Development testing should never be done as user #1 unless testing installation or update routines. In fact, nothing but install and update should be done as user #1. See http://drupal.org/node/22284 - Ken Rickard agentrickard On 7/26/07, Karoly Negyesi <karoly@negyesi.net> wrote:
user #1 sees all
Yup. user 1 has all possible rights, there is a special check for it so that every kind of access check is TRUE for this user. In this case, node administrators can see all nodes and because user 1 has every right, she is also a node admin.
You should write your own hook_db_rewrite_sql and not muck with what's in node.module. You should not have to muck with it. If you've installed a module that implements hook_node_grants() and hook_node_access_records(), then you must rebuild the node_access table. See Administer >> Content management >> Post settings >> Rebuild permissions. If you've not installed a module implementing those hooks, and you want complete control over who sees what (that is, you don't want node_db_rewrite_sql to affect anything), then you have to manually remove the default entry in the node_access table (where gid is 0, nid is 0, and realm is 'all'). If that entry is present, the node module lets everyone view everything. There is a little-known module called devel_node_access, in the devel module, which you should be using, just to show you which nodes are protected. It provides a block which you should enable in the footer. As far as your user #1 issues are concerned, remember that user_access() always returns true for user #1. So that user generally has unrestricted access to everything. -Dave On Thursday 26 July 2007 00:06, Ron Parker wrote:
Currently, I patch the node.module's node_db_rewrite_sql() function. What I would like to do is take this functionality and put it into a separate custom module so that I don't have to patch the core module.
I was advised to take the code, place it in my custom module, and weight my custom module heavier than the node module. Tried that, but I'm getting some serious errors.
i'll go further, and suggest that you should not implement that hook in your module either. you want to restrict nodes using the node access API, just like og itself. See the example node_access module on api.drupal.org Dave Cohen wrote:
You should write your own hook_db_rewrite_sql and not muck with what's in node.module. You should not have to muck with it.
If you've installed a module that implements hook_node_grants() and hook_node_access_records(), then you must rebuild the node_access table. See Administer >> Content management >> Post settings >> Rebuild permissions.
If you've not installed a module implementing those hooks, and you want complete control over who sees what (that is, you don't want node_db_rewrite_sql to affect anything), then you have to manually remove the default entry in the node_access table (where gid is 0, nid is 0, and realm is 'all'). If that entry is present, the node module lets everyone view everything.
There is a little-known module called devel_node_access, in the devel module, which you should be using, just to show you which nodes are protected. It provides a block which you should enable in the footer.
As far as your user #1 issues are concerned, remember that user_access() always returns true for user #1. So that user generally has unrestricted access to everything.
-Dave
On Thursday 26 July 2007 00:06, Ron Parker wrote:
Currently, I patch the node.module's node_db_rewrite_sql() function. What I would like to do is take this functionality and put it into a separate custom module so that I don't have to patch the core module.
I was advised to take the code, place it in my custom module, and weight my custom module heavier than the node module. Tried that, but I'm getting some serious errors.
Dave Cohen wrote:
You should write your own hook_db_rewrite_sql and not muck with what's in node.module. You should not have to muck with it.
This entire effort is to that end. I have written my own hook_db_rewrite_sql. I have tested it *in* the node module, and am now trying to put it into a separate module, and the node module back to it's original code.
As far as your user #1 issues are concerned, remember that user_access() always returns true for user #1. So that user generally has unrestricted access to everything.
I understand this perfectly. But, if I create a group view, and as user #1 look at that view, I should see all nodes IN THAT GROUP. What I am saying is that once I implement my new hook_db_rewrite_sql in a separate module, and return the node.module to its default, unmodified state, as user #1 when I look at that view, I see every node in the database. I understand that user #1 can see everthing, but aparently there is something about the implementation of my hook_db_rewrite_sql that corrupts the normal view restrictions and causes every node in the database to be listed no matter what the view. Again, here is my hook_db_rewrite_sql() code: function og_user_roles_db_rewrite_sql($query, $primary_table, $primary_field) { if ($primary_field == 'nid' && !node_access_view_all_nodes()) { $return['join'] = og_user_roles_node_access_join_sql($primary_table); $return['where'] = og_user_roles_node_access_where_sql(); $return['distinct'] = 1; return $return; } } Further along: <>function og_user_roles_node_access_join_sql($node_alias = 'n', $node_access_alias = 'naa') { if (user_access('administer nodes')) { return ''; } $return = 'INNER JOIN {node_access} '. $node_access_alias .' ON '. $node_access_alias .'.nid = '. $node_alias .'.nid '; ...my own custom modifications // I use node_access_alias = "naa" instead of "na". This is to avoid the "duplicate table alias" error. So, my question is: Why is this hook_db_rewrite_sql code in a custom module creating a circumstance where views no longer work as user #1 when the same code does NOT create this problem when replacing the node_db_rewrite_sql function in the node.module? I'm ThisClose to making this all work after several months of banging my head against the wall, so any suggestions are much appreciated. Thanks! -ron -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com
On Thursday 26 July 2007 10:48, Ron Parker wrote: [snip]
So, my question is: Why is this hook_db_rewrite_sql code in a custom module creating a circumstance where views no longer work as user #1 when the same code does NOT create this problem when replacing the node_db_rewrite_sql function in the node.module?
Sounds like the node.module code is granting access, where your code is not. Look for enties with realm 'all' in the node_access table.
I'm ThisClose to making this all work after several months of banging my head against the wall, so any suggestions are much appreciated. Thanks!
My suggestions are: 1) Install devel module and enable the query log. Look at the exact SQL that is the result of all the rewriting. And 2) Enable devel_node_access and see what it has to say. And of course 3) debug your problem. I'm also going to reiterate what Moshe said earlier. Think long and hard before implementing your own hook_db_rewrite_sql. The grant hooks can do quite a lot for you. Sounds like you may know what you're doing - I don't mean to imply that you don't. -Dave
Dave Cohen wrote:
On Thursday 26 July 2007 10:48, Ron Parker wrote: [snip]
So, my question is: Why is this hook_db_rewrite_sql code in a custom module creating a circumstance where views no longer work as user #1 when the same code does NOT create this problem when replacing the node_db_rewrite_sql function in the node.module?
Sounds like the node.module code is granting access, where your code is not. Look for enties with realm 'all' in the node_access table.
Actually, it was the exact opposite: My new code was granting access. I resolved it by adding code that exempts user #1 (or any user with "administer nodes" permission).
I'm ThisClose to making this all work after several months of banging my head against the wall, so any suggestions are much appreciated. Thanks!
My suggestions are: 1) Install devel module and enable the query log. Look at the exact SQL that is the result of all the rewriting. And 2) Enable devel_node_access and see what it has to say. And of course 3) debug your problem.
I did install devel module. Thanks for the suggestion.
I'm also going to reiterate what Moshe said earlier. Think long and hard before implementing your own hook_db_rewrite_sql. The grant hooks can do quite a lot for you. Sounds like you may know what you're doing - I don't mean to imply that you don't.
Again, you are right. I actually used the hook_node_access_records() in another module to create the exact permission grants I needed for private access to work without hook_db_rewrite_sql(). Problem here is I've not though through a way to grant permissions that take into account OG, TAC and Content Access (CA) access control. I can assure you I take everything you suggest as an effort to help, and apprecite it as such. Using the node access API is a much better way to go, no question about it. I just have not figured out how to do it as efficiently or effectively as I have with hook_nodeapi and hook_db_rewrite_sql. Thanks for all the help! -ron
-Dave
__________ NOD32 2424 (20070726) Information __________
This message was checked by NOD32 antivirus system. http://www.eset.com
-- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com
participants (6)
-
Dave Cohen -
Karoly Negyesi -
Ken Rickard -
Konstantin Käfer -
Moshe Weitzman -
Ron Parker