Users have reported (http://drupal.org/node/54633) denied access to the site contact page (http://www.example.com/contact) for users who are logged in. Having just experienced this problem I spent a day debugging it...
The problem could be described as either unclear documentation or a bug in the code. It's that permissions granted to anonymous users aren't automatically given to authenticated users as well.
On the Access Control page, for example, if you scroll down to the Node Module and check Access Content for the anonymous user and leave it unchecked for all other roles, logged in users (with the exception of User 1) will not be able to access nodes such as the site contact page.
If this is considered a bug, there are two possibilites for fixing the code. In the user.module, in the user_access function, you can change the relevant part of the db.query from "IN (%s)" to "IN (1,%s)", which forces inclusion of the anonymous user permissions when doing permission lookups.
Another option is to change the user_load function. This is where the actual error is, but fixing it here could have ramifications elsewhere. In this case, note this section of code:
$user->roles = array();
if ($user->uid) {
$user->roles[DRUPAL_AUTHENTICATED_RID] = 'authenticated user';
}
else {
$user->roles[DRUPAL_ANONYMOUS_RID] = 'anonymous user';
}
In the first branch of the if statement, both roles should be given to logged in users, like so:
$user->roles = array();
if ($user->uid) {
$user->roles[DRUPAL_ANONYMOUS_RID] = 'anonymous user'; // give logged in users all permissions of anonymous users
$user->roles[DRUPAL_AUTHENTICATED_RID] = 'authenticated user';
}
else {
$user->roles[DRUPAL_ANONYMOUS_RID] = 'anonymous user';
}
This bug was difficult to find because access permissions are cached for users. To empty the cache (menu:[userID]:[language]), change something on the access control page and save it.
Comments
Comment #1
RobRoy commentedI'm thinking this is by design, and feel like I've seen a related issue as to why authenticated users don't get the combined permission of the anonymous role as well (since they really aren't a member of that role at that moment).
Comment #2
googhome commentedIf the code is by design, then there's an issue with the documentation, which doesn't make clear that wackiness happens if you give a permission ONLY to the anonymous users.
Comment #3
RobRoy commentedGood point. Go ahead and open another issue for improving the access control help text on that page to make this clearer. Create an issue against 5.x-dev as you'll get more visibility there and then any change will be backported to 4.7.x if possible.