<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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: <a
href="http://drupal.org/node/122173:"
title="http://drupal.org/node/122173:">http://drupal.org/node/122173.</a>
I've documented those efforts here: <a class="moz-txt-link-freetext" href="http://groups.drupal.org/node/3700">http://groups.drupal.org/node/3700</a>
However, that's a discussion for another day.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Nor can I define why the /node/add works when the user has devel.module
permissions turned on.<br>
<br>
-ron<br>
<br>
Larry Garfield wrote:<br>
<blockquote cite="mid8902ad2953cfaf1b1f946ee161548f6f@localhost"
type="cite">
<pre wrap="">Ron,
I have to ask. Would this be easier for you if this patch went in: <a class="moz-txt-link-freetext" href="http://drupal.org/node/143075">http://drupal.org/node/143075</a>
Your task sounds like exactly the sort of thing that patch would simplify. Please correct me if I'm wrong, though.
</pre>
</blockquote>
You are right, if in fact this is working.<br>
<blockquote cite="mid8902ad2953cfaf1b1f946ee161548f6f@localhost"
type="cite">
<pre wrap="">
On Tue, 22 May 2007 12:24:38 -0700, Ron Parker <a class="moz-txt-link-rfc2396E" href="mailto:sysop@scbbs.com"><sysop@scbbs.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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
(<a class="moz-txt-link-freetext" href="http://www.mysite.com/">http://www.mysite.com/</a> 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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">A few weeks back I floated my og user roles module idea on this
list as instructed by CVS Admin. This module (<a class="moz-txt-link-freetext" href="http://drupal.org/">http://drupal.org/</a>
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-
</pre>
<blockquote type="cite">
<pre wrap="">roles. user_access (which returns permissions allowed according
</pre>
</blockquote>
<pre wrap="">to roles) is called by node_access which is what determines
access on a node/ add.
I recently proposed a $user->roles hook (<a class="moz-txt-link-freetext" href="http://drupal.org/node/">http://drupal.org/node/</a>
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, <a class="moz-txt-link-freetext" href="http://www.mysite.com/">http://www.mysite.com/</a>
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 <a class="moz-txt-link-freetext" href="http://www.scbbs.com">http://www.scbbs.com</a>
Self-Administration Web Site <a class="moz-txt-link-freetext" href="http://saw.scbbs.com">http://saw.scbbs.com</a>
SDSS Subscription Mgmt Service <a class="moz-txt-link-freetext" href="http://sdss.scbbs.com">http://sdss.scbbs.com</a>
Central Ave Dance Ensemble <a class="moz-txt-link-freetext" href="http://www.centralavedance.com">http://www.centralavedance.com</a>
R & B Salsa <a class="moz-txt-link-freetext" href="http://www.randbsalsa.com">http://www.randbsalsa.com</a>
</pre>
</blockquote>
<pre wrap="">
__________ NOD32 2277 (20070518) Information __________
This message was checked by NOD32 antivirus system.
<a class="moz-txt-link-freetext" href="http://www.eset.com">http://www.eset.com</a>
</pre>
</blockquote>
<pre wrap="">
--
Ron Parker
Software Creations <a class="moz-txt-link-freetext" href="http://www.scbbs.com">http://www.scbbs.com</a>
Self-Administration Web Site <a class="moz-txt-link-freetext" href="http://saw.scbbs.com">http://saw.scbbs.com</a>
SDSS Subscription Mgmt Service <a class="moz-txt-link-freetext" href="http://sdss.scbbs.com">http://sdss.scbbs.com</a>
Central Ave Dance Ensemble <a class="moz-txt-link-freetext" href="http://www.centralavedance.com">http://www.centralavedance.com</a>
R & B Salsa <a class="moz-txt-link-freetext" href="http://www.randbsalsa.com">http://www.randbsalsa.com</a>
</pre>
</blockquote>
<pre wrap="">
__________ NOD32 2285 (20070522) Information __________
This message was checked by NOD32 antivirus system.
<a class="moz-txt-link-freetext" href="http://www.eset.com">http://www.eset.com</a>
</pre>
</blockquote>
<pre wrap="">
--
Ron Parker
Software Creations <a class="moz-txt-link-freetext" href="http://www.scbbs.com">http://www.scbbs.com</a>
Self-Administration Web Site <a class="moz-txt-link-freetext" href="http://saw.scbbs.com">http://saw.scbbs.com</a>
SDSS Subscription Mgmt Service <a class="moz-txt-link-freetext" href="http://sdss.scbbs.com">http://sdss.scbbs.com</a>
Central Ave Dance Ensemble <a class="moz-txt-link-freetext" href="http://www.centralavedance.com">http://www.centralavedance.com</a>
R & B Salsa <a class="moz-txt-link-freetext" href="http://www.randbsalsa.com">http://www.randbsalsa.com</a>
</pre>
</blockquote>
<pre wrap=""><!---->
__________ NOD32 2285 (20070522) Information __________
This message was checked by NOD32 antivirus system.
<a class="moz-txt-link-freetext" href="http://www.eset.com">http://www.eset.com</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Ron Parker
Software Creations <a class="moz-txt-link-freetext" href="http://www.scbbs.com">http://www.scbbs.com</a>
Self-Administration Web Site <a class="moz-txt-link-freetext" href="http://saw.scbbs.com">http://saw.scbbs.com</a>
SDSS Subscription Mgmt Service <a class="moz-txt-link-freetext" href="http://sdss.scbbs.com">http://sdss.scbbs.com</a>
Central Ave Dance Ensemble <a class="moz-txt-link-freetext" href="http://www.centralavedance.com">http://www.centralavedance.com</a>
R & B Salsa <a class="moz-txt-link-freetext" href="http://www.randbsalsa.com">http://www.randbsalsa.com</a>
</pre>
</body>
</html>