[development] The static $perm variable in user_access reset erroneously

Sat Nov 1 04:27:05 UTC 2008

Another minor point regarding this debug,  Since you're not dumping  
all of the $perm variable, we don't really know that the user_id is  
the same. What if the user_id was being checked?  (we know which was  
being modified) Would recommend debugging print_r($account,1) and  
print_r($perm,1) after the reset line.

On Oct 31, 2008, at 8:55 PM, David Metzler wrote:

> I downloaded and looked at the code for user_access and I have one  
> idea.  I've had some problem intializing static structures to  
> arrays or objects in certain versions of php.  Try changing the  
> definition of $perm as follows:
>
> static $perm = '';
> if (!$perm) $perm = array();
>
> See if that changes the caching behavior in your php rev.
>
> Dave
>
>
> On Oct 31, 2008, at 11:38 AM, Ron Parker wrote:
>
>> On Fri, Oct 31, 2008 at 12:27 AM, David Metzler  
>> <metzlerd at metzlerd.com>wrote:
>>
>> > It sounds like you're suggesting that $perm, a static variable  
>> within
>> > user_access() is being modified without user_access being  
>> called, but within
>> > a single page load.   That doesn't seem possible in PHP, unless  
>> there is a
>> > PHP bug.  Static variables are supposed to be local in scope to the
>> > functions that create them. To prove beyond a shadow of doubt,  
>> put a $debug
>> > statement in at the very beginning of the function user_access  
>> and another
>> > at the very end of the function.  (just before the return).  If  
>> what you're
>>
>> This is exactly what I'm suggesting.  I put debug statements in  
>> user_access, node_content_access, and my OGUR function so that I  
>> would see every time they were accessed, and what was in them.
>>
>> To briefly summarize, I have a role "GroupAdmin" which is  
>> dynamically added to the $user object.  It contains the "create  
>> story content" permission.
>>
>> I issue the command to clear the $perm cache: user_access 
>> ('ClearCache', NULL, TRUE)
>>
>> This is followed by a module_invoke command (which, in turn will  
>> again call user_access):
>> module_invoke('node_content', 'access', 'create', 'story', $user)
>>
>> The problem is that the $perm variable in the second user_access  
>> call should contain the values from the first user_access call,  
>> and it doesn't.  It is still set, as it should be, but the  
>> variables are different.  Here are the results of my debugging:
>>
>> I noticed that even when my hook_init() clears the $perm variable:
>> user_access('', NULL, TRUE)
>> ogur roles loaded into user object (hook_init)
>> user_access | string =
>> user_access | static $perm is NOT already set
>> user_access | $perm set for uid 3 (test01)
>> user_access | string = | $perm values =  
>> 0,1,2,0,1,2,4,5,7,8,9,10,4,5,6,7,8,9,10,0,0,1,2,3,4
>> user_access | roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin)
>> user_access | permissions returned: (access comments,access  
>> content,view uploaded files,view advanced help index,view advanced  
>> help popup,view advanced help topic,post comments,post comments  
>> without approval,search content,use advanced search,subscribe to  
>> newsletters,view links in block,create page content,create story  
>> content,delete own page content,delete own story content,edit own  
>> page content,edit own story content,upload files,configure member  
>> roles,access devel information,display source code,execute php  
>> code,switch users,view devel_node_access information)
>> The very next call to user_access does NOT contain the correct  
>> permissions:
>> user_access('access content')
>> user_access | string = access content | $perm values =  
>> 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4 (note that all the permmissions  
>> from above are NOT here - the only ones missing are those granted  
>> by the dynamically assigned roles)
>> user_access | static $perm is already set
>> user_access | roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin)
>> user_access | permissions returned: (view advanced help index,view  
>> advanced help popup,view advanced help topic,access comments,post  
>> comments,post comments without approval,access content,search  
>> content,use advanced search,subscribe to newsletters,view links in  
>> block,access devel information,display source code,execute php  
>> code,switch users,view devel_node_access information)
>> Another test:
>>
>> This is the page loaded:
>>
>> http://mysite.com/node/ognodeadd?type=story&gids[]=24
>>
>> User should be able to create story. This is what debug returns:
>> ogur roles loaded into user object (ognodeadd)
>> ogur | ognodeadd roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin)  These are the correct roles  
>> for this user in this group.
>> ogur | module to call = node_content | type = story
>> ogur | Preparing to call module_invoke
>> ogur | Calling user_access('ClearCache', NULL, TRUE)
>> user_access | string = ClearCache
>> user_access | static $perm is NOT already set
>> user_access | $perm set for uid 3 (test01)
>> user_access | string = ClearCache | $perm values =  
>> 0,1,2,0,1,2,4,5,7,8,9,10,4,5,6,7,8,9,10,0,0,1,2,3,4
>> user_access | roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin)  This is correct.
>> user_access | permissions returned: (access comments,access  
>> content,view uploaded files,view advanced help index,view advanced  
>> help popup,view advanced help topic,post comments,post comments  
>> without approval,search content,use advanced search,subscribe to  
>> newsletters,view links in block,create page content,create story  
>> content,delete own page content,delete own story content,edit own  
>> page content,edit own story content,upload files,configure member  
>> roles,access devel information,display source code,execute php  
>> code,switch users,view devel_node_access information)
>>
>> The above are the permissions that $perm should have the next time  
>> user_access is ran.  It will run again when module_invoke() is  
>> called. Below is what comes back the very next time user_access is  
>> called.
>> ogur | Calling module_invoke('node_content', 'access', 'create',  
>> 'story', $user)
>> node_content_access | type = story | op = create
>> node_content_access | roles returned: (authenticated  
>> user,Devel,Group Member,Group Contributor,Group Admin)
>> user_access | string = create story content | $perm values =  
>> 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4
>> user_access | static $perm is already set
>> user_access | roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin) This is correct.
>> user_access | permissions returned: (view advanced help index,view  
>> advanced help popup,view advanced help topic,access comments,post  
>> comments,post comments without approval,access content,search  
>> content,use advanced search,subscribe to newsletters,view links in  
>> block,access devel information,display source code,execute php  
>> code,switch users,view devel_node_access information)
>> Note that the "Group Admin" role permissions are not included  
>> here. They should be the same as from from the ClearCache  
>> user_access command above. It appears that the above permissions  
>> have been cached somewhere else.
>> ogur | module_invoke called
>> ogur | ognodeadd roles returned: (authenticated user,Devel,Group  
>> Member,Group Contributor,Group Admin)
>> ogur | module_invoke access returns false
>> Access should be true here.
>> Installed devel module.  There are four user_access SQL queries  
>> that appear on this page:
>> 1.16	1	user_access	SELECT p.perm FROM role r INNER JOIN permission  
>> p ON p.rid = r.rid WHERE r.rid IN (2,8)
>> 0.77	3	user_access	SELECT p.perm FROM role r INNER JOIN permission  
>> p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7)
>> 0.76	3	user_access	SELECT p.perm FROM role r INNER JOIN permission  
>> p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7)
>> 0.72	3	user_access	SELECT p.perm FROM role r INNER JOIN permission  
>> p ON p.rid = r.rid WHERE r.rid IN (2,8,3,4,7)
>>
>>
>>
>>
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081031/622a5af2/attachment.htm 