[development] OG User Roles: user_access / node add / $user->roles

Bill Fitzgerald bill at funnymonkey.com
Tue May 22 21:57:55 UTC 2007


Ron,

We've been looking into similar issues here as well -- see this topic  
http://drupal.org/node/49385 which sheds a little bit of light on the 
fact that user_load() isn't called early on every page view -- Moshe 
confirmed in an email to the group a while ago:  
http://lists.drupal.org/pipermail/development/2006-February/013851.html

I never entered an issue, but this might be the time.  It certainly 
seems logical to me to expect a fully-loaded global user object on every 
page load.

Bill

Ron Parker wrote:
> I created two watchdog notices: One in user_access (showing $string 
> and result: true/false) and one in the hook_user "load" (showing roles 
> returned) operation.
>
> I logged in as user in question, went to groups, clicked on "create 
> link", got "Access denied".
>
> One of the roles that is returned by the og modified $user->roles 
> gives this user the permission to "create link".  The watchdog entries 
> verify that for the url in question: /node/add/link?gids[]=29,  the 
> correct roles are returned in $user->roles and the correct access in 
> user_access.  Yet access is denied.
>
> Does the following bit of information provide a clue?:
>
> When I load the "devel" module, and give this user access to it 
> (through access control), the user does not receive "Access denied" 
> message when clicking on "create link".  If I go into access control, 
> and remove permissions for "devel" module, the user still continues to 
> be able to "create link".  However, if as admin I delete the cache, 
> run cron.php, logout and log back in as user, the "Access denied" 
> message returns.
>
> It seems that if this is a cache problem, clearing the cache doesn't 
> appear to resolve it.
>
> I really appreciate any insight.  I've been working on cracking this 
> for 8 months now.  It's driving me nuts because there must be 
> something somewhere, either in user_access or node_access or some 
> other hook that's if I only knew I could correct the problem.
>
> Thanks so much!
>
> David Metzler wrote:
>
>> Thinking about this maybe the problem is user_access, not the roles  
>> themselves.  Check out the user_access function in user.module.  
>> Note  that is uses a static variable caching mechanism, so it may 
>> have  already determined the results of "user_access" before you've  
>> modified the roles.  (It would need to in order to route the request  
>> and check access permissions).
>>
>> One way to check would be to call user_access immediately after you  
>> set the roles, and see if it gives you the proper result, (in your  
>> watchdog or debug files).
>>
>> The bad news is that I don't really know of a good way to solve this  
>> if that's the case. I'm afraid that we need a hook_user_access in  
>> core in order to implement this.  Either that or an added parameter  
>> to force user_access to ignore the cache.
>>
>> Here's hoping I'm wrong :).
>>
>> Dave
>>
>>
>> On May 21, 2007, at 3:39 PM, Ron Parker wrote:
>>
>>> Thanks so much for the reply.  Here's what I tried in hook_init:
>>>
>>> function og_user_roles_init ()
>>> {
>>>    global $user;
>>>    $roles = og_user_roles_all_roles($user); // This returns normal  
>>> $user->roles and includes OG roles if any
>>>    $user->roles = $roles;
>>>    $displayRoles = implode(",", $roles);
>>>    if ($user->uid) watchdog('og_user_roles', 'user roles = ' .  
>>> $displayRoles); // Show this in log if it hits.
>>> }
>>>
>>> Here's what I tried in hook_user:
>>>
>>>    // Add the group roles to $user->roles if this is a group
>>>    // This should only be effective until the next global $user call
>>>    if ($op == "load") {
>>>        $roles = og_user_roles_all_roles($user); // This returns  
>>> normal $user->roles and includes OG roles if any
>>>        $user->roles = $roles;
>>>    } // end $op load
>>>
>>> I looked at the watchdog and my own debug file, and the correct  
>>> roles are being returned each and every time.
>>> My guess is that $user->roles is doing what it should, but there is  
>>> something else happening in the node/add
>>> (http://www.mysite.com/ node/add/link?gids[]=29) process that  
>>> doesn't depend upon $user->roles that is causing the access denied  
>>> error.
>>>
>>> Again, any clues would be much appreciated.
>>>
>>> -ron
>>>
>>> David Metzler wrote:
>>>
>>>> I've run into similar problems with using user_load to alter   
>>>> user_data.  User_load doesn't fire as often as you might think it   
>>>> does due to some caching strategies.   To prove this, place a   
>>>> drupal_set_message call in your user_load trap and see when it   
>>>> fires.  It may not be firing on the page where you're getting the   
>>>> access denied errors.
>>>>
>>>> To solve my problem I had to move user alteration into the init hook.
>>>>
>>>> It may be that there's core bug here, but I haven't yet tracked  
>>>> it  down since the init hook solved my problem.
>>>>
>>>> I never did find out why user_load wasn't firing.
>>>> On May 15, 2007, at 11:56 AM, Ron Parker wrote:
>>>>
>>>>> A few weeks back I floated my og user roles module  idea on this   
>>>>> list as instructed by CVS Admin.  This module (http://drupal.org/  
>>>>> node/87679) is designed to assign roles to OG group members that   
>>>>> are specific to the groups they are in.  The problem was that I  
>>>>> had  to patch the core user.module in order to get it to work.
>>>>>
>>>>> After a couple of suggestions, I decided to formulate a proposal   
>>>>> for a Drupal hook.  What I thought made the most sense was either  
>>>>> a  user_access hook or a $user->roles hook because what I wanted  
>>>>> to do  was add roles to the site wide roles returned by $user- 
>>>>> >roles.   user_access (which returns permissions allowed  
>>>>> according to roles)  is called by node_access which is what  
>>>>> determines access on a node/ add.
>>>>>
>>>>> I recently proposed a $user->roles hook (http://drupal.org/node/  
>>>>> 143393), and someone pointed out that I could accomplish the  
>>>>> same  thing by using the existing hook_user "load" operation.   
>>>>> They were  right.  I modified my module to add the appropriate  
>>>>> roles to the  user object using hook_user "load" and in testing,  
>>>>> it appears that  $user->roles now returns the OG group as well as  
>>>>> the site wide  roles when a user is in a group.
>>>>>
>>>>> However, on a group node add, for example, http://www.mysite.com/  
>>>>> node/add/link?gids[]=29, my user gets an "Access denied" error.   
>>>>> I  wrote a little debug program that writes out the values  
>>>>> returned by  my hook_user "load" addition, and every time it's  
>>>>> called it returns  the correct values.
>>>>>
>>>>> node_access would be the access control for a group node add.  I   
>>>>> have examined the code closely, and this is the only code that   
>>>>> would be executed on a node "create":
>>>>>
>>>>>  // Can't use node_invoke(), because the access hook takes the  
>>>>> $op  parameter
>>>>>  // before the $node parameter.
>>>>>  $module = node_get_types('module', $node);
>>>>>  if ($module == 'node') {
>>>>>    $module = 'node_content'; // Avoid function name collisions.
>>>>>  }
>>>>>  $access = module_invoke($module, 'access', $op, $node);
>>>>>  if (!is_null($access)) {
>>>>>    return $access;
>>>>>  }
>>>>>
>>>>> This code would then call "node_content_access" (hook_access for   
>>>>> node), which would use "user_access" (thus calling global $user,   
>>>>> thus invoking my modification) to determine access.
>>>>>
>>>>> So, I'm at a complete loss as to why I would get an "Access  
>>>>> denied"  error for a group role.  I need some help!
>>>>>
>>>>> The only thing I have noticed which seems to give me a clue is  
>>>>> that  when I load the "devel" module and give users access,  
>>>>> everything  works.  But, I can't figure out what the devel module  
>>>>> is doing that  would cause this.
>>>>>
>>>>> Any hint, clue or anything would be appreciated.  Thanks!
>>>>>
>>>>> -ron
>>>>>
>>>>> -- 
>>>>> Ron Parker
>>>>> Software Creations               http://www.scbbs.com
>>>>> Self-Administration Web Site     http://saw.scbbs.com
>>>>> SDSS Subscription Mgmt Service   http://sdss.scbbs.com
>>>>> Central Ave Dance Ensemble       http://www.centralavedance.com
>>>>> R & B Salsa                      http://www.randbsalsa.com
>>>>>
>>>>
>>>>
>>>> __________ NOD32 2277 (20070518) Information __________
>>>>
>>>> This message was checked by NOD32 antivirus system.
>>>> http://www.eset.com
>>>>
>>>>
>>>>
>>>
>>>
>>> -- 
>>> Ron Parker
>>> Software Creations               http://www.scbbs.com
>>> Self-Administration Web Site     http://saw.scbbs.com
>>> SDSS Subscription Mgmt Service   http://sdss.scbbs.com
>>> Central Ave Dance Ensemble       http://www.centralavedance.com
>>> R & B Salsa                      http://www.randbsalsa.com
>>>
>>
>>
>> __________ NOD32 2285 (20070522) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>>
>>
>>
>
>


-- 
Bill Fitzgerald
http://www.funnymonkey.com
Tools for Teachers
503.897.7160



More information about the development mailing list