Anonymous can't see a node even though DNA claims he should

You should start by following the procedure that is displayed when you click on http://drupal.org/node/add/project-issue/forum_access — don't create a new issue in the FA queue though, just follow that procedure and report here...

EDIT: This started out as an issue about Content Access showing nodes to Anonymous when it shouldn't, but it evolved more and more into a discussion about Devel Node Access and it has already lead to various improvements of DNA. As of #26 I'm moving this issue to the Devel queue, because we're now dealing with a case of DNA claiming that Anonymous should have access when he hasn't.

What is your problem? You post a reply with

You can start by being a little less rude. I posted to the content
access project, not the forum access project. Either something is wrong
in Drupal and you are seeing my issue in the forum access project queue
OR you aren't paying attention. Either way, try thinking before spatting
off.

and then you go back and erase the text?

I wasn't being rude in the least and I was fully aware of where you posted — I merely pointed you in the direction that would quickly lead to a useful discussion. It might even enable you to solve the problem yourself.

Since you marked this as critical, it seemed to make sense to try to help you...

Maybe YOU should "try thinking before spatting off," and you owe me an apology.

(Comments are not just displayed here, but they are distributed immediately by email to everyone who is subscribed. IOW, editing does not undo posts.)

No, I'm not implying that it is your error (nor that it really is a bug), but in this area it's just about impossible to get a clear picture from what you (or anyone) writes in prose. Node Access is very complex and without DNA neither you nor anyone else can begin to guess what is happening on your system. Prose is simply a waste of time.

With DNA's debug mode we can see the full node access data for one specific node, and then we can begin to discuss what we see. Please post the full table, there's valuable information in every row and every column. Or even better, attach a screen snapshot of the table.

The meaning of the gid depends on the realm. Post the full information and your chances for getting help increase dramatically...

Reset priority to 0. You shouldn't change that unless you have more than one node access module and you want to try to prioritize among them.

I don't understand what you mean with

I set the advanced value to -10 to override the core permissions (0 and 1 didn't work).

In what way did 0 work less than -10?

DNA says that CA grants read access to roles 4 and 5 (moderator and admin) to node 17. There are no inconsistencies as far as node 17 is concerned, and there's nothing that would grant access to Anonymous, yet at the bottom we see that he has read access!

Also, no role should have update nor delete access according to the first table, yet there are a couple of 'yes' entries in the second! Weird...

Now show us content_access_DNA.jpg as seen by a moderator and by an anonymous user.

It's 2:45am here — I'll check in again after getting some sleep...

Ah, so you're confirming that setting priority to -10 hasn't helped over leaving it at 0, right? That would have been most surprising.

Thank you for the additional snapshots. So, admin and moderator both have administer nodes. I wouldn't give it to the latter — after all you're already using CA, which can grant Edit and Delete rights.

The second table should list the reason for access rather than just 'yes', that would be much more helpful. (I happen to be the maintainer of DNA, although not the author of the second table.)

The reason for the unwanted access seems to be the 0/0/all/100 record in the {node_access} table. That's what "Access Granted to All Nodes (All Users)" on the NA Summary is trying to say. If you delete that record, things will probably be close to normal. However, several questions are open, like why is that record there, and as you wrote, if it gives problems to you, it's bound to cause problems for others, too, so I hope you're willing to explore this further rather than aiming for a quick exit...

1. First look up and write down the NIDs of the two nodes that are allegedly not visible go normal users by clicking on the "2" under "Legacy nodes". We need to keep an eye on those. Right now they should still be visible to Anonymous because of the 0/0/all/100 grant.
2. Drupal should remove that record the moment you enable any node access module. Please disable CA and confirm that this has removed all {na} records except for the 0/0/all/100 one. Then reenable CA and confirm that {na} is now empty. Then re-set the CA settings (read access to story for moderator and admin and to some other content type for role 2). This should produce the same {na} entries that you showed, except for 0/0/all/100, which shouldn't be there.

   Now verify that users without administer nodes cannot see the two "Legacy nodes" anymore. You'll have to set CA for their content type as well, so that they can become visible.

   This is how it should work in principle. If it repeatably doesn't work that way, there's a bug in either CA or Drupal. We need to further discuss this once we have your results.

3. If the 0/0/all/100 grant is gone, then please put it back in manually. Click on [Rebuild permissions] on admin/content/node-settings. This should also remove the 0/0/all/100 record. Does it?
4. What disturbs me is that DNA is NOT showing the 0/0/all/100 record! That seems to be a DNA bug that I need to fix!
5. BTW, your theme does not correctly define the colors for the 'ok', 'warning', and 'error' classes. They should typically be green, yellow, and red, rather than even/odd striped blue. These same colors also appear on admin/reports/status, if the theme defines them properly.

Thank you for pursuing this!

I've been playing with CA and I'm a bit confused about what happens when I disable and enable it. It's probably better to not just disable but also to uninstall it and then start over.

What I wrote in #9.2 is not correct. Enabling CA should not result in an empty {na} table (as I wrote) but in a table that has one NID/0/all/100 record for each node. And the 0/0/all/100 record must be gone.

What you show in content_access_table_CAturnedbackon.jpg is bad, but I was unable to reproduce it. The 0/0/all/100 record causes all nodes to be visible to everyone. This makes all other records ineffective as far as View is concerned. Enabling any node access module should replace the one 0/0/all/100 record with NID/0/all/100 records, one for each node. The resulting behavior at this point is the same, but from then on, each node can be controlled separately, without any side effects on any other nodes.

The story content type won't engage in the NA table. you can see that the NIDs end with #15.

But not having any record for some nodes is bad, too, because these would disappear (if it weren't for that bogus 0/0/all/100 record). What does DNA show you for the story nodes?

NID/0/all/100 (the Drupal default) corresponds to CA's default of access to anon and auth. If you change a content type, CA does the following for each node of that type: it replaces the one NID/0/all/100 record with one or more NID/RID/content_access_rid/100 records, one for each role that you have given View permission.

Now verify that users without administer nodes cannot see the two "Legacy nodes" anymore. You'll have to set CA for their content type as well, so that they can become visible.

Not sure I understand. I looked at nodes 21 and 23 as anonymous before starting the process above. Images are attached showing what I saw.

This was based on the assumption that you'd have removed the 0/0/all/100 record. If it's still there, everyone can still see those nodes, of course. Don't they have any DNA information?

I am ready for next level testing. If you want me to manually remove 0/0/all/100 next time around, that's cool.

First really do disable and uninstall CA and then reenable it. Is 0/0/all/100 still there?

If yes, then try something else: uninstall CA and install ACL (just for testing). This should produce the same set of NID/0/all/100 records and no 0/0/all/100. Does it?

This test should tell us whether we're dealing with a CA problem or with a CA-independent NA problem...

Without CA installed, if I set core permissions to not allow anonymous to view content, anonymous can still see the teaser of the node but when you click to see the rest of the node, you get access denied. This makes sense to me.

You mean access content? I thought should not see teasers, not even titles, but I'm not really sure. IAC you should give access content and let NA control it.

I have been assuming that CA would do the same thing. Set a content type such that anonymous cannot see the full node but anonymous can still see the teaser in a View or published to the front page or even in a taxonomy term list.

NO, not at all. If NA is active then users who don't have View cannot see any trace of the nodes in question. At least that's how it should work. There are buggy modules out there that don't properly enforce NA, and those can leak parts of or even entire nodes, but that's not how it's supposed to work.

I ask this because one of my clients has a Drupal site and has CA installed (I didn't set up the site). When CA is set to not allow anonymous to see a particular content type, it removes all those content type nodes from the a teaser view. Is that what is intended with CA?

Yes, that's how all NA modules are supposed to work!

Just for the sake of completeness, you do see the messages from Drupal that ask you to rebuild permissions sometimes, don't you? And you do the rebuilding when requested, right?

Start by uninstalling CA. You'll be left with one entry in {na} and a clean slate.

Oh, and BTW, I've updated DNA so that it detects and reports that unexpected 0/0/all/100 record. It's not flagged as an error though, only as a warning, because it's possible that someone would actually want to have it that way. But they'd have to go out of their way to do it.

The update will be in Devel 6.x-1.x-dev after it has been repackaged (within 12h).

The rebuild permissions requests from Drupal (in the message area) and from DNA (in the DNA block) are two different things. Certain events inside Drupal cause Drupal to realize that it must rebuild permissions, and that's when it flashes that message. OTOH, the DNA message comes up when DNA finds inconsistencies between the {na} table and the information that the modules would return to Drupal if Drupal were to rebuild the permissions. Drupal would never find these inconsistencies on its own and would just limp along with whatever data is in {na}.

I just installed ACL and the NA table remained unchanged. Given ACL is an API I assume there isn't anything to do but install. So maybe this isn't a CA issue? I hate it when this happens.

Correct. It seems like something on your site is trying to optimize NA and keeping Drupal from exploding the 0/0/all/100 into NID/0/all/100s.

Even though you can't interact directly with ACL, Drupal recognizes it as an NA module and behaves accordingly. I think Drupal should ask you to rebuild permissions after you've enabled ACL (or any other NA module).

Yes, now it looks good.

The 'yes' for Anonymous is odd, but what exactly is 'Anonymous'? I don't see it here. Is it an account that you have created and called 'Anonymous'? If that's the case, then 'Anonymous' is an authenticated user, not an anonymous one! If you want to 'impersonate' an anonymous user, you have to log out.

You're welcome. You have highlighted a very important possible glitch that the first DNA block didn't catch so far. I've implemented it now, and this is a great improvement for DNA, which will ultimately help with support for all NA modules. So I got something out of it, too, and I appreciate your perseverance in testing and posting updates.

The all-or-nothing property is not a feature of CA but of the node access mechanism in core. This mechanism does rely on the cooperation of every module that displays lists of nodes though: the module must feed its queries through db_rewrite_sql(). Modules that don't do that are considered buggy, but if you find a module that presents the list as you want it, you can simply remove that db_rewrite_sql() call, and you get all nodes. Clicking on a read-more link will go to an error page though.

You may also want to look at the Premium module. Maybe it does what you want.

Ah, yes, now I see it too. I have 10 accounts on my test system and Anonymous as the eleventh wasn't showing. :-) I'll look into it.

Thank you for your offer to do testing! Besides DNA I maintain Forum Access, Image Gallery Access, ACL, and Subscriptions. Do you have any interest in any of those?

I've looked into why Anonymous might have read access, and it just doesn't fit together...

What I see here is that if CA is installed and we're looking at a content type that hasn't been configured, then that content type defaults to read access for anonymous and authenticated. DNA shows this as in ca_default (the second row). However, you're not showing such a NID/0/all/100 record in the DNA snapshot nor in the {na} table.

Could it be that Anonymous is the author of node/17 and might have access because of that?

What do you see when you log out and look at node/17? Can you really view it? What does DNA say about why you can see it?

sorry for the delay in replying. How can i get email notices when someone posted on one of my issues?

No problem. To get email, click on the "Issues" link in the breadcrumbs at the top of the page, and then "Subscribe".

This has grown out of scope for CA and I'm moving it to the Devel queue.

There has been an effort in #309765: More info for why user is allowed/denied access to essentially duplicate the code from node.module to be able to tell why access is granted, but this got stuck along the way. We now have a case of DNA claiming Anonymous has View access (as returned from node_access()!), yet Anonymous gets access denied. So, even though I'm not very fond of that code duplication, we now need the result.

I'll come up with a patch. You do know how to apply patches, idcm, right?

Sorry about taking so long. I was hoping we could fix a bug in core (#470840: Bug in node_access if we specify an account when check the filter_access), which would have made this task easier.

Anyway, here's the patch. The instructions for applying patches are on http://drupal.org/patch/apply.

I hope this will give us a clue as to why Anonymous can't see that node. If it doesn't, I'll have to work on it some more...

Ah, here's the patch.

Actually, I committed this after the favorable feedback I got in #559522-2: DNA shows different update permission depending on sign in a while ago. In the meantime I've tuned it some more and ported it to D7, too.