Access Denied to Anonymous Users when used with another node access module
pcorbett - August 24, 2007 - 00:04
| Project: | Content Access |
| Version: | 5.x-1.3 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | fago |
| Status: | closed |
Jump to:
Description
I have a page that is viewable by all. When I apply any kind of content access control on it (even if I just go to the access control tab on the page and click "submit" after doing nothing but that), the page becomes inaccessible to all except the administrator. Is this by design? If so, what I want to be able to do is allow everyone to view a certain page (including the public/anonymous) but only allow certain users and/or roles to edit the page. Any help would be much appreciated.
#1
hm, no that's not desired. If the module is activated and the settings aren't touched, then nothing should change. But if so, would modules have you installed else and which drupal version are you using?
#2
Sorry, I wasn't being very specific. Basically, when enable node-level access control and add an individual user to be able to edit that one particular node, the user is then denied access to that page rather than giving them edit privileges.
I have three roles: administrative user, content editor, teacher. Admin can always do everything. Content editors can edit any page. and Teachers I want to have access to only a couple pages. However, when I simply add a teacher user to be able to edit a particular note, they then receive an access denied error as well as anonymous and authenticated users... they cannot view the page either - access denied.
So, very basic setup and I assume I'm missing something but not sure what.
Any thoughts?
#3
I'm having a similar, if not the same, problem. With node level control on, if I change any permissions on that node the anonymous user is then locked out. If I give the anon user edit permission then he can view it but obviously also edit, if I then remove the edit permission leaving with just view he is back to being locked out.
I can fix this by hand by modifying the database but a proper fix would be good.
#4
Could this be something to do with the cache? I don't know how the drupal cache works but I've just been playing with a few pages and a guess is that if you visit a page that is blocked that page gets cached. If the block is removed but the flag (whatever) isn't set to say that the content has changed the cache won't be updated so the page will stay locked.
I'm going to have a play and see what I can come up with.
#5
hm, might be a cache problem. I don't think that the cache is reseted when you change node access. Could you try if clearing the "cache_page" table fixes the problems for you?
If not, what are the exact settings to reproduce?
* per node settings
* allow view anonymous view access to one single node, while view access per content type isn't granted?
#6
I think the problem is related to some logic inside the ACL module.
What happens is that if you switch to the access control tab and then save the form, entries get created in the {acl} and {acl_node} tables, but if you don't fill in anything in the specific user fields on that tab, nothing gets created in the {acl_user} table.
Then inside acl_node_access_records, it has this:
if (acl_has_users($grant['gid'])) {$grants[] = $grant;
}
else {
//just deny access
$grants[] = array('grant_view' => 0, 'realm' => 'acl', 'gid' => 0);
}
and so the above "just deny access" clause gets used when it comes time to write into {node_access}.
At this point I'm not familiar enough with the intended way you're supposed to use the acl module to know whether this is purely a bug in acl, or if there's something else that needs to be added to content_access to make this work properly.
#7
I'm having the same problem. I hope this gets fixed soon.
#8
Same problem here as well with drupal 5.5 and latest acl and content_access (not -dev).
Everything is fine with content for anonymous users as long as you don't touch any acl settings. When you do, the guest user will get a access denied error. Adding the guest (or Gast) user to have granted view access per user, doesn't work either because the user is unknown.
Neither rebuilding permissions nor truncating the database cache tables help. Granting edit rights to anonymous users helps, but really this is no option of course. ;)
#9
<?phpfunction node_access_write_grants($node, $grants, $realm = NULL, $delete = TRUE) {
if ($delete) {
$query = 'DELETE FROM {node_access} WHERE nid = %d';
if ($realm) {
$query .= " AND realm in ('%s', 'all')";
}
db_query($query, $node->nid, $realm);
}
?>
The problem is from node.module line 2935, please have a look.
#10
#11
#12
you can try to empty acl table and acl_node table
#13
For those interested, I've had more luck with the node access module, although that has its own set of issues - or rather, unclear descriptions of what certain things do and don't do. I don't use content access any longer, so I honestly forget exactly whether the fix andyhu suggested will help my old issue. It would be nice if Drupal had this functionality build into core.
#14
The Content Access module doesn't work with the ACL module, as in the web page says (http://drupal.org/project/content_access). I installed both modules, and the permissions on every page that I applied, doesn't work in a predictable fashion. To be more exact, the all think work with the BookPage content type, but no with the Page content type. But when I uninstalled the ACL module, everything worked great.
#15
Sorry. Accidentally I changed the title. I wanted to change the status. Now it's correct
#16
I don't have a clear picture of what the problem is. General comments like "it doesn't work" don't help us, and I don't understand why it would work with Bookpage but not with Page. It would really help if those who have the problem could explain step-by-step what to do to reproduce one single case of misbehavior.
Also, it would help if you could install the Devel module, enable the node_access entries block and tell us what it shows when it works and when it doesn't.
#17
hm, I think I know the problem. Its' the content access grant optimization code - it writes only grants if necessary. This doesn't respect the fact, that other modules may insert a grant, and so the default view access isn't happening any more.
I'll make a new release without these optimization code.
#18
I shouldn't blame the whole optimization code so quick - it's doing well. However, there was a dumb mistake in there, which should have caused this issue. -> I've fixed this in the latest 5.x-dev release.
Furthermore, now the grants are even a bit better optimized :)
Please test the dev version - I'd like to get some positive test results before creating the 1.3 release.
After updating, be sure that the node grants are rewritten. E.g. edit and save nodes which are hidden.
#19
That seems to have got it!
#21
Automatically closed -- issue fixed for two weeks with no activity.
#22
I also confirm that the problem is corrected for me too and I also want to emphasize that you NEED to keep the content_access priority to 0 for it to work properly. Any other value messes things around.
#23
I have both acl and 5.x-1.3 dev content access modules installed and still have this problem. I have set one node to be editable by an individual, but every time he edits or updates the node, the anonymous user subseqently gets bumped off to the login page. I can clear it by going into the content access tab and resubmitting the permissions.
??
#24
Another note: this happened without the ACL module installed as well
#25
@fago: may I suggest that you follow moshe's advice in http://drupal.org/node/210651#comment-702855 and implement the new
hook_node_access_explain($row)according to the proposal in http://drupal.org/node/205317 ?
This has helped me a couple of times already to resolve issues like this one, and it's especially helpful when more than one access module is involved.
@sijuwi: thanks for eliminating ACL from the issue.
#26
sijuwi, if your problem persists please reopen a new issue - as the original problem is fixed, I reset this issue to fixed.
@salvis: that sounds good, yes.
#27
Automatically closed -- issue fixed for two weeks with no activity.