Closed (fixed)
Project:
Weblink
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
21 Oct 2004 at 07:20 UTC
Updated:
8 Nov 2004 at 10:20 UTC
Jump to comment: Most recent file
Playing with weblink on 4.5 while setting access rules via nodeperm_taxonomy.module, I noticed that Weblink Directory shows in the counters also weblinks that should not visible due to node_permission.
Is there a way to fix this ??
Thanks
Matteo
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | weblink45_compliant_version.patch | 5.87 KB | matteo |
| #5 | weblink.module.patch | 579 bytes | matteo |
Comments
Comment #1
Bèr Kessels commentedcould you see if the released 4.5 has this issue still, and otherwise be so friendly to close this? thanks for the feedback, Bèr
Comment #2
Bèr Kessels commentedcould you see if the released 4.5 has this issue still, and otherwise be so friendly to close this? thanks for the feedback, Bèr
Comment #3
matteo commentedBer,
I tried running 4.5 version, but nothing changes.
I'm running with nodeterm_taxonomy.module, created a 'private' and 'public' term in this taxonomy, and linked all node types to that term.
Story, page, book and forum are compliant to node_access system and do not consider 'private' nodes when you access as a 'public' access user. Trying to view the node gives error, and counts in listing simply do not consider that nodes.
Weblink, instead, lets me view the nodes, and count also 'private' nodes in the directory.
Here is what I found in drupaldocs.org:
Please let me know how I can help.
Matteo
Node access rights
The node access system determines who can do what to which nodes.
In determining access rights for a node, node_access() first checks whether the user has the "administer nodes" permission. Such users have unrestricted access to all nodes. Then the node module's hook_access() is called, and a TRUE or FALSE return value will grant or deny access. This allows, for example, the blog module to always grant access to the blog author, and for the book module to always deny editing access to PHP pages.
If node module does not intervene (returns NULL), then the node_access table is used to determine access. All node access modules are queried using hook_node_grants() to assemble a list of "grant IDs" for the user. This list is compared against the table. If any row contains the node ID in question (or 0, which stands for "all nodes"), one of the grant IDs returned, and a value of TRUE for the operation in question, then access is granted. Note that this table is a list of grants; any matching row is sufficient to grant access to the node.
In node listings, the process above is followed except that 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 node_access_join_sql() and node_access_where_sql() to add the appropriate clauses to your query for access checks.
To see how to write a node access module of your own, see node_access_example.module.
Comment #4
matteo commentedFound what the problem is.
It is explained also in Handbook [node:7176]:
"We have node-level access control now! This means that node modules need to make very small changes to their hook_access() implementations. The check for $node->status should be removed; the node module takes care of this check."
So, this check must be eliminated in weblink_access().
Here is the new code:
Comment #5
matteo commentedHere is the patch:
Comment #6
matteo commentedI forgot to mention that weblink directory continues not to be compliant, since the counts include non viewable nodes.
I'm trying t owork on it, but I have some troubles....
Matteo
Comment #7
matteo commentedAttached, you'll find a patch that makes weblink compliant with node_access, adding the proper node_access controls to SQL selects.
Also, I corrected two problems:
- a refer to 'static' column instead of the new 'sticky' column in one query
- 'old' taxonomy link in blogmark block, not using the new 'taxonomy/term/xx/alll/feed' syntax
I'll continue testing the module, but in the meantime, I would like to know by the maintainers if they agree on the changes.
Sorry, the fix is huge......
thanks
Matteo
Comment #8
Bèr Kessels commentedthanks matteo,
I committed the patch, and think the changes are not that huge at all. I committed only the latsest patch, and I still have no site where I can test the changes ATM.
Furhtermore: could you please wathc the line-endings? the latest patch used windows line endings, while Drupal uses unix endings. It made the patch fail all the time, untill I found out i had to convert the endings in the patch. No big issue, but If its no problem, i prefer unix line endings.
regards and big thanks! Bèr
Comment #9
matteo commentedOk, Ber !
I'm running on windows, and Tortoisecvs creates the patch with dos/windows endings by default.
Next time I'll convert to unix before sending the patch.
CIAO
Matteo
Comment #10
(not verified) commented