[development] OG User Roles: user_access / node add /$user->roles
Ron Parker
sysop at scbbs.com
Wed May 23 05:56:25 UTC 2007
I actually have been using a similar nodeapi patch for some time now
with remarkable success on another project. The Extensible Node
Access/Authorisation Capability patch: http://drupal.org/node/122173.
<http://drupal.org/node/122173:> I've documented those efforts here:
http://groups.drupal.org/node/3700 However, that's a discussion for
another day.
I didn't try using this patch with OG User Roles because I was trying to
get the module to run without *any* core patches. However, prompted by
your e-mail, and months of frustration, I updated my node.module with
the version of the nodeapi patch I've already used.
Initially, it didn't work. Every watchdog I put in (hook_nodeapi,
hook_user, node_access) returned the values I would expect, but I
continued to get "Access denied". I emptied the cache, logged on and
off, etc... Every time I clicked on "create link", it failed.
So, I decided to use the default Drupal access control to give the user
in question the "create link" permission (by giving the permission to
all authenticated users). Of course, when the user clicked on "create
link", it brought up the node submission form.
I didn't notice anything particularly different in the logs, so I
removed the permission from authenticated users. Deleted cache, ran
cron.php, and tried to "create link" again. It worked. Deleted cache,
etc.. again. It still worked.
I logged off and logged back on as a different user. Messed around,
then logged off and back on as the user I've been working with. Clicked
on "create link". It still works.
I guess I should be happy, but I'm not because I know that whatever the
problem was, it's still there. I can neither identify what the problem
is, nor explain why the /node/add is working now.
Nor can I define why the /node/add works when the user has devel.module
permissions turned on.
-ron
Larry Garfield wrote:
>Ron,
>
>I have to ask. Would this be easier for you if this patch went in: http://drupal.org/node/143075
>
>Your task sounds like exactly the sort of thing that patch would simplify. Please correct me if I'm wrong, though.
>
>
You are right, if in fact this is working.
>On Tue, 22 May 2007 12:24:38 -0700, Ron Parker <sysop at scbbs.com> 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
>>>
>>>
>>>
>>>
>>>
>>--
>>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
>
>
>
>
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070522/c611b89c/attachment.htm
More information about the development
mailing list