Access denied to all content for anonymous users

I have the same problem.

Drupal 7.4
views 7.x-3.0-rc1
Content Access 7.x-1.x-dev (2011-Jul-08)

PLEASE search the issue queue before you ask.

#1115794: Conflict with views module

After updating views to the latest dev version I have the same issue. Anonymous users only have access to forum, contact and search pages. At all other pages access will be denied.

I have the same behavior as picsofle.

I need from you the clear steps to reproduce this problem, I can't figure out what's wrong unless I see it on my machine.

I also have a standard installation of Drupal 7.4. Content access was already installed before the update (working properly). After updating content access to 7.x-1.x-dev (2011-Jul-08) anonymous users only have access to forum, contact and search pages. At all other pages access will be denied.

Rebuilding permissions does not solve the problem.

Also installed using latest dev for views, content_access, ctools. Access is denied if both "anonymous" and "authenticated user" are checked for "view any page content"

Seems related to #1212718: View any content does not work when the Anonymous + Authenticated are both checked

Same situation here...

As soon as I turn off "authenticated user" the "anonymous" access control begins to work properly.

Having the same problem on this end with latest version of Content Access. Running 7.4 Drupal.

Hi,

having same problem as listed in http://drupal.org/node/1212718 which is the same as refered to in #8

Thanks
Rich

Replicated on my install as well, running D7.4.

Is there any other option for Content Type-level access restriction for D7 that I'm not aware of, or do I need to be patient and wait for the next dev version of this module?

Regardless, I'm appreciative of the work completed on this port thus far.

Thanks,
Matt

I'm having this problem as well after upgrading to D7.4 and CA7.x-1.x-dev. I had to disable CA to fix for now.

Sub.

Same here. This only applies to anonymous users. Any other roles that are created are not affected.
Did someone spell autenticatid wrong maybe?
Lord knows I have a tough enough time spelling it!
I have this on a production site and (fortunately) users are either anonamouse or in a dedicated role. Nobody is merely "othentacated".
Looking forward to a fix though as this is a great module.

Thanks for the module and I hope you at least got a little chuckle here.

MrPhilbert

subscribing... not much more I can add, same version of Drupal and views. can't see any nodes but can see blocks so long as they aren't related to nodes (i.e., client has a bunch of blocks with custom html content). I am able to see other entities like Profiles created by Profile2 module and so my views showing profile2 information still work.

**EDIT: I went into a few content types and removed authenticated but it didn't work.

I'm having the same problem after upgrading to Content Access 7.x-1.x-dev version from July 8.
Was already using Core D7.4 with no problems before the upgrade.

Since the Content Access upgrade suddenly access is denied anonymous users.

Going into into each content type and removing Authenticated solves the problem.

It is an excellent module, and hopefully this problem can be solved soon.

On D7 disabling the Content Access module allows accessing from anyone, but of course this is not a solution.
Still waiting for this very important patch.

As far as I can say:

EVERY SAVING of a node writes wrong permissions for the node into the node_access table. (see attachment)

In column "realm" is the value "content_access_all". If I set the value manually to "all" the node is accessibly by anyone.

DO NOT REBUILD PERMISSIONS, this will result in all nodes having the realm "content_access_all". (see attachment)

I don´t think this has anything to do with views, as I have this error an all nodes

No relation with views. About #18, there is also a worse case: when you modify something, that node becomes no accessible again (since the realm is set to 'content_access_all' after any modification).

Yes, that's exactly what I wanted to say with

"EVERY SAVING of a node writes wrong permissions for the node into the node_access table"

:-)

Same issue here. Subscribing for solution.

Come to think of it, that's what got me started. I modified a node, saved it and it disappeared from view.
When I rebuilt permissions, everything disappeared.

Does reverting to previous version of CA solve the problem?

#16 works. Thanks lyd.
De-selecting 'view any ### content' for 'authenticated user' (and keeping the selection for 'anonymous user') in any content type makes that particular content type visible again to anonymous users.

P.S.Initially tried deselecting 'view published content' for 'authenticated user' in drupal global permissions, but did not solve the problem.

if we apply #16 it works for anonymous users, but for the authenticated ones the problem still remains open!

Subbing. Menu entries are also prevented from being seen because of this.
I agree with #20.

On lines 507-512 of content_access.module, you'll see:

  // Detect if all are allowed to view
  $all = array(DRUPAL_ANONYMOUS_RID, DRUPAL_AUTHENTICATED_RID);
  if (count(array_diff($all, $rids['view'])) == 0) {
    // Grant view access to all instead of single roles
    $rids['view'] = array('all');
    $grants['all'] = array('realm' => 'content_access_all', 'gid' => 0, 'grant_view' => 1, 'grant_update' => 0, 'grant_delete' => 0, 'priority' => content_access_get_settings('priority', $node->type));
  }

If we change the $grants['all'] realm to "all", this should be correct. I think what's happening is "content_access_all" was just a typo left-in following other naming conventions throughout this module.

I'll generate a patch sometime today.

Give this patch a try.

You folks are fast

Patch from #27 appears to be working for me after permissions rebuild. Thanks!..

Forgot to set the needs review flag for #27.

Patch from #27 works for me too. Thanks!

Great patch and a terrific, quick response!

Thanks

Confirmed, patch form #27 worked for me. Thanks wjaspers!

It works also in my case. thank you to all.

Mostly just subscribing because I bumped into this problem today..

Not sure what to do with the patch on post 27..

How long does it usually take for patches to get into the downloadable module?

I don't need it right now but will soon so I can disable Content Access until a new version with the patch is available..

Thanks for a great module, combined with ACL it looks like it will give me the full permissions control I am looking for..

Use Netbeans to patch.

Till then, here is the module that I patched.

Additionally, this patch is pretty simple so you could open up the .module file and do it manually. The - beside the first line means delete that line in the code and + means to add that line in... the other lines referenced in the patch are contextual and shouldnt' be touched, they just help identify where in the code the changes are required.
pete

Patch #27 worked for me! Thank you all.

Patch in #27 works fine for me too. Changing issue status.

see also: http://drupal.org/node/1212718

Verified bug in D7 with dev version from today.

Patch works for me. Thanks :-)

See also: http://drupal.org/node/239139

Patch #27 worked for me too. Thanks a lot.

subscribing

I can't accept patch in #27 since I changed it in #239139: Do not hijack the 'all' realm I'll try to find what's going wrong.

subscribing.

shouldn't this be critical?

subscribing

The patch in #27 solved some(/all?) issues here too!

Also confirm that patch #27 resolved issue.

Patch in #27 fixed things for me after a rebuild of perms. Thank you.

Good to have confirmation about the patch working but it still doesn't conform with good_man's comments about hijacking the 'all' realm in #45. I think we should be turning our attention to that now rather than continuing to confirm/test the patch.

@morningtime: the module is in *dev* so that means don't use it on production sites, ever.

Commit reverted, please retest and tell me if it the bug is gone.

I arrived at this problem by this bug: http://drupal.org/node/1227090#comment-4769836
Solution was to disable all "pages" in page manager and start enabling them till it worked again.

Subscribing

Subscribing

Subscribing

Subscribing

This issue was caused by a commit for #239139: Do not hijack the 'all' realm, which has since been reverted and should be resolved by updating your module to the latest dev version.

I just updated to the latest dev version (released August 9), and anonymous users are still denied access to all content.

@jesss have you used devel module to check the node access records stored in the database? Did you rebuild permissions after updating?

For me 7.x-1.2-beta1 appears to be working fine as long as the "book navigation" block is disabled completely.. The block is not critical for me but access control is..

Simply rebuilding the permissions didn't work, but disabling and re-enabling the module, then rebuilding permissions again seems to have done the trick. Thanks!