Closed (won't fix)
Project:
Content Access
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
10 Nov 2009 at 23:39 UTC
Updated:
17 Jun 2011 at 22:05 UTC
The access control on one of our client's sites got completely hosed during the D5 => D6 upgrade. It suddenly made Content Access in charge of everything, which is NOT the way things behaved in D5. This causes it and Organic Groups to fight a bitter, merciless battle.
Here is the one example grants array coming from node_access_acquire_grants() in D5:
Array
(
[0] => Array
(
[grant_view] => 0
[realm] => content_access_rid
[gid] => 0
)
[1] => Array
(
[realm] => og_admin
[gid] => 2
[grant_view] => 1
[grant_update] => 1
[grant_delete] => 1
)
[2] => Array
(
[realm] => og_public
[gid] => 0
[grant_view] => 1
[grant_update] => 0
[grant_delete] => 0
)
)
Here it is again in D6:
Array
(
[0] => Array
(
[grant_view] => 1
[grant_update] => 0
[grant_delete] => 0
[realm] => content_access_rid
[gid] => 5
[priority] => 8
)
[1] => Array
(
[grant_view] => 1
[grant_update] => 0
[grant_delete] => 0
[realm] => content_access_rid
[gid] => 19
[priority] => 8
)
[2] => Array
(
[realm] => og_admin
[gid] => 2
[grant_view] => 1
[grant_update] => 1
[grant_delete] => 0
[priority] => 0
)
[3] => Array
(
[realm] => og_public
[gid] => 0
[grant_view] => 1
[grant_update] => 0
[grant_delete] => 0
[priority] => 0
)
)
I noticed that on the working D5 site, none of the checkboxes on the Access control tab are checked. In D6, it now auto-selects "Authors can view their own content" and force-selects the roles that have administer nodes permissions. So now instead of these nodes being controlled by OG, suddenly Content Access has taken over, and denies access to everyone who isn't the author, or who doesn't have administer nodes permissions.
No. Bad! :(
Comments
Comment #1
webchickOne relatively easy way to fix this is just to add another checkbox to the interface for "Enable Content Access control of this type." Then exempt the results of content_access_node_grants() if it's not an allowed type. This would allow CA to play nicely with other access control modules, who have control over other types.
Comment #2
webchickIncidentally, this is a similar issue to #431176: Conflict CA and Organic Groups OG Access but not exactly the same, IMO, since it deals with the upgrade path rather than your typical configuration conflicts between two node access modules.
I think basically what should happen is we should add that Content Access module on/off flag per type, and during the upgrade path if there are no access control options selected for a given type, set its flag to "Off."
Does this make sense?
Comment #3
salvisGenerally, your first move should always be to install devel_node_access (part of Devel). This will show you (almost) all you ever wanted to know about node access on any given installation. You've gone the hard way and traced out some grants, just enough to let us diagnose the problem:
CA has a priority of 8. This is bad. Open the Advanced fieldset and set it back to 0.
Enable DNA's debug mode before you make the change and look at a node before and after — it will be enlightening!
BTW, priority being at 8 is not the result of upgrading but of someone fiddling with "Advanced" controls without understanding what they do.
Comment #4
webchickYes, I realize the net cause of the error, and how to diagnose it. But the fact is, it's behaving differently than it did in D5, and this has caused nothing but issues for us, and I imagine others even if they'd left the priority setting alone. See all of the reports in #431176: Conflict CA and Organic Groups OG Access as proof.
In D5 it was enough to not check off any options on the Access Control screen for a type, and that effectively turned the Content Access module's access controls to "Off." This is no longer possible in D6, because Content Access options are forced on for every content type in a misguided attempt to be "helpful."
Is there a reason we can't just add a simple boolean on/off toggle rather than messing with priorities? The priority setting is a complete wtf because you have no idea how it relates to the priorities of your other node access modules without dinking around in the database or with dd().
Comment #5
salvisWhat's different from D5 is that modules have started to use the priority value. AFAIK, all D5 contrib modules left it at 0.
Messing with priority is not the answer — instead you should just clear all checkboxes for the content types that you want to be controlled by OG and not by CA.
I agree that CA's turning on View for anonymous and authenticated is misguided. But I don't see any advantage of adding another checkbox over just unchecking the existing two checked ones.
Again, I recommend DNA, which shows you this and much more in a very readable format. Are you trying to prove something by not using the proper tool?
(BTW, I'm not involved with CA, but I did significantly expand DNA.)
Comment #6
webchickAnd therein lies the problem. You can't. Even if you uncheck the silly author view checkbox, it force-checks any roles with "administer nodes" permissions. So instead of getting a row about content author in Devel Node Access, you now get a row for each role with "administer nodes" perms. There is no longer, as of D6, a simple way to tell Content Access to butt out and leave your poor content alone.
Now, you instead need to override Content Access's forced behaviour by setting its priority field down to -10 or whatever, so that OG takes precedence. And you need to do this on every content type, even if you only want CA to control one of them. And now, instead of interacting with a straight-forward list of access options, end users are forced to be jammed straight into the intricacies of Drupal's node access system. There are about 10 people on this planet who have any idea what a "node grants priority" is, and messing with this setting is how my client ended up gunking up their upgrade path in the first place. :)
So we should either restore the ability to uncheck everything here like we could in D5, or we should add another setting to turn CA off completely per content type. The current situation represents a major regression, and it breaks the D5 => D6 upgrade path.
Comment #7
webchickOh, about this:
DNA will show you the grants that were ultimately used on a given node, but it does not show you the list of candidate grants. To get that information, you have no choice but to throw debugging code into node_access_acquire_grants().
I am not trying to "prove" anything other than a bug exists, and I had to spend significant amount of time tracking down why. That kind of tone is not helpful.
Comment #8
salvisGo to devel#edit-devel-node-access-debug-mode and enable debug mode; it'll show you the candidate grants.
That's true, but users with administer nodes have View access anyway, and those grant records ensure that the nodes (where the user has View access) do actually show up in node listings. Without those grant records, in the presence of any NID/realm/100 by any NA module, admins would not get those nodes in node listings. So you could actually think of this as a public service of CA. Every NA module has to do that. Obviously, it would be nice if core did it, but it doesn't...
So, if a node is controlled by another NA module (like OG), those grants don't make any difference, and they may actually be beneficial. The only problem is for nodes that are not controlled by any other NA module, because they won't get core's NID/all/100 and thus they'll disappear, if you remove the two checkmarks. But the behavior is still reasonable, after all you've removed access to anonymous and authorized — you get what you ask for.
I'm sorry if you find my tone unhelpful. It's not meant to be that. You're seeking help and I'm trying to provide it. You ignored my advice in #3, making it unnecessarily difficult for both of us to discuss the actual issues. Please post a screenshot of the debug DNA records of a specific node if you have more questions. This information allows me to see what's happening on your site and to discuss a specific case. Without that information we're both in the dark and we're limited to talk about generalities.
You are capable of tracking things down eventually (few people are), but you could have saved your "significant amount of time" (as well as mine) and probably solved the problem by yourself in the first place by installing DNA from the start.
Comment #9
webchick?!?!?
I must really not be communicating properly here, or... something.
I did use DNA from the start, which is how I discovered that Content Access module's grants were overriding what used to be OG's grants after the upgrade. I did not know about the Debug mode of DNA (and thanks for that), so indeed had to go the hard way of dd()ing inside node_access_grants() to discover exactly where/how OG's grants were being trampled on. You're exactly right that it was a misconfiguration of the priority property that caused OG's access control to be ignored. I discovered that myself well in advance of #3. I never have disputed that this was the cause.
What I said was that this was all working just fine in Drupal 5, because it was possible to turn off Content Access module, and so this misconfiguration never took effect. In Drupal 6, it's not possible to turn the module off; Content Access is forced on for you, no matter what you do. Your only recourse is to fiddle with the priority setting so that OG or whatever takes precedent. So when you go through the 5 => 6 upgrade, suddenly Content Access module's grants end up getting tossed into the mix even if this was disabled in D5. This is totally unexpected behaviour and in this case it completely hosed their node_access table.
I realize that Content Access is just making plain for you what node_access() is doing automatically, but I do not want this. I don't want an extra N grants to iterate through on each node access request, I don't want an extra N records in my node_access table, I don't want to have to debug two layers of grants when I run into node access-related bugs, and I don't want to have to explain the node grants priority system to clients who want to get their site to behave the way that it used to.
I just want this module to behave as it did in Drupal 5, where I could disable its access control when I want to hand it over to another module. The fact that I can't do this (without setting CA's priority down to -1, which is completely non-intuitive) certainly feels like a critical bug to me.
Comment #10
salvisI agree, this should not happen. I don't really know how CA behaves during the upgrade — fago needs to answer to that.
Turning off View for anonymous and authenticated for the OG content types should have been enough to return the site to normal operation though. If these really were turned on automatically during the upgrade, then I agree that it's a bug.
If you want to avoid CA's admin grants, then a master checkbox per content type is a good idea.
Comment #11
webchickI don't have my normal computer on me atm, so I'll have to look again once I get it back to see if re-weighting the priority to 0 and removing the checkbox on author on these content types is enough to restore access. I've tried so many things at this point that I forget which conditions cause what now.
I do know that I still get Content Access rows in DNA after doing that... this time about my "Editor" and "Web Admin" roles, since they have 'administer nodes' permissions, but you're right that these shouldn't conflict with what node_access() normally does. So the behaviour should appear the same, even if I'm getting twice the number of grants "under the hood."
It looks like at the very least, content_access_update_6001() needs some checking to see whether or not CA's access control was disabled before, and if so, don't add any additional grants. But I have a feeling due to the way the UI works that unless a per-content-type on/off toggle is added, by virtue of visiting the content type's access control page and saving it, you'd end up with CA rows in node_access again, and be unable to remove them without reducing the priority level setting.
Tentatively switching the title and category on this issue once more. At the very least, I think we're both agreed that something needs to get fixed. :)
Comment #12
salvisRight. And the grants for "Editor" and "Web Admin" should only be queried for users holding those roles, so general performance should not suffer. But I agree that being able to remove those grant records is desirable.
I've been thinking about this some more, and I'm beginning to have doubts whether these grant records really do have a purpose (i.e. whether they're queried at all). It seems that users with administer nodes can enumerate nodes even without them...
However, I maintain that the behavior resulting from CA during normal operation (OG being overwridden when anonymous and authorized have access through CA) is correct and consistent. If that access is enabled during the D5->D6 upgrade, then that's clearly a bug. We may be wrestling with two separate issues here.
Comment #13
good_man commentedCan't test on Drupal 5 now, if you are really in need for such a behaviour reopen it.