Posted by gianfrasoft on September 10, 2008 at 3:53pm
| Project: | Nodeaccess |
| Version: | 5.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
If I clean the author's field on a new content, the author is anonymous for that one. So this is may be edited by any user, also if not logged on Drupal front-end.
Can I disable this issue without putting the author name on any content?
Thanks.
Comments
#1
#2
#3
At admin -> user management -> access control, under the section "node module", how are the "edit own xxxx content" permissions set for the role "anonymous"?
#4
The edit own xxxx content permissions are ALL set to false.
#5
What happens if you disable all contrib modules? And perhaps optional core modules? And maybe clear (for now) all "edit own xxxx content" and "edit xxxx content" permissions. I can't reproduce the problem.
#6
I found problem is in Nodeaccess module, in whitch I can't exclude edit permission to anonymous user if, for the same module, the author has permission to edit content of a specific node type.
For example, if the anonymous user can only view a specific content but author can also edit id, in Nodeaccess I see something like this:
Role View Edit Deleteanonymous user *
other user 1 *
other user 2 *
author * * *
I need to do this because I want that every user can edit only his own content and anoymous user can't create or edit anything on the site. But, so I can't deny anonymous user to change his own content.
Moving permission from author to other users isn't a solution because they will grant permission to edit content made by others.
It would be better if Nodeaccess module get author permissions and, after that, overwrite default role permissions for the node type denying thoese are not set. In my example on the above, anonymous user should only view his content even if he is the author.
Can I do this?
Thanks.
#7
Do you need to use nodeaccess for the nodes in question? If you just use the standard roles/permissioning system then it should work the way you want...?
#8
I just got bit by this one as well, or something very similar.
I wasn't actually using nodeaccess for anything yet, just had it installed and enabled, but hadn't touched the settings.
Seems that Drupal's default behaviour with a piece of content is to make the author anonymous if the author field is left blank. The author field was left blank after an edit, and immediately the content became editable by anyone visiting the site.
It's a dangerous default to give the author full permissions since it is so easy to make the author anonymous, or have a bunch of anonymous authored content lying around when you first enable the module.
Just to be sure, tested this out with a clean install of nodeaccess on a test site without any settings changed, and content with an empty author is immediately editable by anyone visiting the site.
#9
Thanks, mrf.
I can definetively say that the possible solutions are two:
1. add in Nodeaccess "deny edit" and "deny delete" properties with an higher priority then other properies (even on the anonymous user);
2. don't allow the Author Settings for "Node author" properties on anonymous users.
#10
The issue here is that "edit own" permissions aren't being taken into consideration. You can verify this also by giving view/edit/delete permissions to a role (authenticated users) for example and take away all "edit any" and "edit own" permissions to the roles. You will see that you'll still have the access granted by nodeaccess.
1. add in Nodeaccess "deny edit" and "deny delete" properties with an higher priority then other properies (even on the anonymous user);
Due to how hook_node_grants is implemented, this isn't a possibility.
2. don't allow the Author Settings for "Node author" properties on anonymous users.
This may be a solution, but I think some people might want this still. Maybe a configuration option for this is the better way to go.
I think a better solution would be to implement checks for edit own, edit any, delete own, and delete any in nodeaccess_access.
#11
Any fix for this? This is a big, big security vulnerability--for example, by default, a user's nodes are assigned to Anonymous when a user is deleted. With this bug in nodeaccess, it results in anyone having author-level access to the nodes.
There's no reason for the anonymous user to be treated like other users. It's not actually a user, it's just a placeholder for no user.
#12
grant view permission to a node not working using nodeaccess untill we enable the following permission at admin -> user management -> access control, under the section "node module",
is there any solution to solve this issue ?
#13
zohera: sounds like a separate issue, so I'd suggest creating a separate issue for it.
#14
About my solution:
andyl56 says:
Yes, I think this is the simpliest solution to a very big problem. Do we go?
#15
Subscribing.
#16
I am using the 6.x version of the module and was running into the same problems. I just wanted to ping this thread to say that I've created created a patch for 6.x at #959358: Create additional permissions for anonymous authors.
#17
Changing version back.
#18
andyl56 says:
No config option needed, that's what the Anonymous User row is for. Unless you want to give anonymous users access only to nodes where their author has been deleted. I can't see a use case for that.
#19
I think a solution is becaming indispensable.
I'll check the code asap.
#20
Mine isn't a very good solution, but it's what I just put in place on our site while I look further into the issue and consider applying #959358: Create additional permissions for anonymous authors. I changed node_user() to reset ownership of a deleted user's content to the admin account (uid 1) rather than anonymous (uid 0). For my employer's website this is a sufficient short-term fix, but I may opt to deploy jbylsma's solution.
#21
I have disabled the node author from being able to edit any nodes and rebuilt permissions; anon is still able to edit the specific node where the author was deleted.
Edit: My bad, I should have cleared cache. The edit form was cached for anon users.
The previous comment works well, but if you don't want to hack core you can create a custom module with 1 function in it:
<?php/**
* Implements hook_user().
*/
function mymodulename_user($op, &$edit, &$user) {
if ($op == 'delete') {
db_query('UPDATE {node} SET uid = 1 WHERE uid = %d', $user->uid);
db_query('UPDATE {node_revisions} SET uid = 1 WHERE uid = %d', $user->uid);
}
}
?>
Just make sure this module has a heavier weight than node.module.
Another edit: I wanted to be absolutely sure that an anonymous user can never edit or submit a node; on our site this is the desired behavior. The following function, thrown into a custom module, will achieve that:
<?phpfunction mymodulename_nodeapi(&$node, $op) {
// Always disable anonymous editing.
if ($op == 'prepare' || $op == 'presave' || $op == 'validate') { // Yes, this is probably overkill and only 'prepare' is likely needed.
global $user;
if ($user->uid == 0) {
drupal_access_denied();
}
}
}
?>