Access denied when creating node if restricted to a role assigned by og_user_roles and i18n is enabled

Hi there,

I am having the same issue ... using a minimal install of Drupal (6.16) + OG (6.x-2.1) + OGUR (6.x-4.1).

1. I have defined only 2 group specific roles: group admin & group member.
2. Both roles have the right to create group content (a specific content type)
3. Roles are assigned (manually or as default role when joining the group)
4. The "Create content" is available in the navigation menu when visiting the group homepage (as expected)

But

• Users with either role receive a "Access denied: You are not authorized to access this page." when trying to create content
• Only if I give sitewide access (for example giving access to "authenticated user") are they able to create content (but it defeat the purpose of using OGUR)

Any help would be welcome ... The strange thing: I am using the devel module to display node access rights, but I don't get anything on the "Access denied" page.

Final remark: my site is not located at the root of the webserver (i.e. pages are served from http://localhost/project_name and not http://localhost). It seems there was an issue with that configuration for OGUR version 1.X (1.5, 1.6) ... is it still an issue with version 4.1?

update 1:

• The issue is only in creating new content ... when the content already exist, the user is able to modify it (assuming the role allows him to do so).

update 2:

• The issue seems related to the fact that the gids parameter is not passed in the url to create documents within the group
• If entering manually http://localhost/project/node/add/CONTENT_TYPE?gids[]=N where CONTENT_TYPE is the content to be created (such as page, story or your own user defined type), and N is the NID of the group that the user is a member of, And ONLY then I am able to create the content.
• So I guess the navigation menu is not to be used to create content by users, my question is then: how are users supposed to create content?

final update:

• To answer my own question (see update 2), to add content to a group can be done by users once you enable the block "Group details" that display various information about the group, as well as link to content type that can be created within the group. And the link provided work as expected.

Cheers,

Sylvain

I can confirm the behavior and work around from comment #1. Will the navigation menu be supported, or will the details block / custom menu need to be utilized?

I am seeing the same issue with "Access denied - You are not authorized to access this page". I also am running i18n on my site. Appreciate any help in resolving.

I found a partial solution to some of the issues.

In the function og_user_roles_menu_get_item(), there is a note that states "OGUR: Allow privilege escalation; always load map.". The person who put this note commented out the check to see whether access was allowed to the menu router_item. In looking through the rest of the Drupal code though, it needs the access element to be true to allow access to an item. So after the lines:

      // OGUR: Allow privilege escalation; always load map.
      //if ($router_item['access']) {
        $router_item['map'] = $map;
        $router_item['page_arguments'] = array_merge(menu_unserialize($router_item['page_arguments'], $map), array_slice($map, $router_item['number_parts']));
      //}

I added the following:

      // CHANGE: Need to set access to true and save changes to core menu_get_item function
      $router_item['access'] = 1;
      menu_get_item($path,$router_item);

This allowed a user who only had group content posting privileges to create a page node using the following type of page creation link:

http://[path to drupal site]/?q=en/add/node/page&gids[]=244

Now, if later this same user wants to translate the node, there is a problem. The URL that the translation add page link provides is like the following:

http://[path to drupal site]/?q=en/node/add/page&translation=262&language=zh-hans

This now brings up a blank page. I think this maybe an oversight (bug?) in Drupal core in the node_add() function. Somehow this should either give us a page not found error or access denied.

Any way, if we change the above link to:

http://[path to drupal site]/?q=en/node/add/page&translation=262&language=zh-hans&gids[]=244

Then the create page form appears as desired.

It seems like, if these changes I have shown above are the right ones, we still need to consider how to handle the following cases:

Adding a page using the main navigation create page link:
http://[path to drupal site]/?q=en/add/node/page

Adding a translation to a page:
http://[path to drupal site]/?q=en/node/add/page&translation=262&language=zh-hans

Opps. I just noticed that I am using the 6.x-4.1 version not the 6.x-4.x-dev version that this issue was reported with. I will need to check the dev version out and see if that removes the need for my changes as it appears it does as I re-read the comments about more closely.

I have now tested with 6.x-4.x-dev and the problem remains. My two line hack does continue to partially resolve the issue for me but I would like to find something more robust.

@spacereactor - not sure why you would get that error as a result of adding those lines. maybe you have a typo.

Let me add that I have verified that if I disable the i18n module, these problems go away just like @spacereactor stated in #6.

Okay. Scratch the above changed in comment #8. It was causing other issues, such as a regular node/add/page giving a page not found error and I decided to delve in deeper into the code.

What I discovered is that although og_users_role_init() runs and alters the user roles and permissions earlier on, it also happens to as a side-effect set the menu router item for the node/add/page or whatever path in the process. The problem is that at the time the menu router item gets set, the system hasn't determined that the user has rights to access that path.

Once this menu router item is set, the system will not try to determine it again.

I looked around in menu.inc for some sort of router_item reset function but did not find one so instead I brought over some of the code from menu.inc and used that to "re-get" the menu item and then use that new router item to go back and set the router item correctly.

Not sure if that is clear but if you look at the patch, I think it will be clearer than my attempt to describe it here.

What I am not sure of is whether this is an appropriate way to handle things. For example, I have to call what I think is intended as an internal function to menu.inc, _menu_translate(). Is that okay? Is there a better way to accomplish this?

Would appreciate if I could get feedback on whether this is the right approach.

Thanks!

I wrote a comment over on #794548: Once install i18n, OG user role stop working regarding this issue and in the process another idea came to mind on how to solve this. This patch takes a slightly different approach by working around the i18n issue. The idea is that the only reason i18n being installed is a problem is that it introduces the possibility of calling menu_get_item() before we have all of our access permissions altered. In looking at the i18n code though, it seems that if the i18n_selection_mode is off than menu_get_item() will not end up being called (or at least not so early in the process).

This patch simply saves the original selection mode, resets the selection mode to off and finally restores the original selection mode before leaving the og_user_role_init() function.

Which patch is the better way to go?

One more thing to note is that neither of these two patches addresses the problem mentioned in #1 that gids[] parameter must be past with a create node request. This is not critical for a brand new page but is problematic for translations because their is no add translation link that appears in the Group Details block.

I guess for now, I can ask users to manually added the gids[] parameter but that isn't going to really make sense to them so I would prefer to have a more user friendly solution.

One idea would be to check the node that the translation is for and get its group id and then use this in lieu of the gids[] parameter.

I also wonder if something like this could also be done so that the create content option from the navigation menu could be used as well. In this case, it could see what groups the user is able to post to and then use one of them to provide a gids[] parameter for the create operation.

Hi there,

After solving my issue (see comment #1), I actually ended up being bitten by the bug Once installed i18n, OGUR stop working, and while investigating the issue I noticed that installing the module "OG Content Type Access" would solve the issue (I did not really investigate more than that, because I was not keen on using this module, hence I removed it and got "stuck" with a new "Acess Denied" message [different from the one in #1]).

Applying patch #14 seems to solve the problem on my side. Thanks again.

Cheers,

Sylvain

Guys,

I found a problem in my patch provided in #14. It was causing the language to be complete turned off. The following patch, I believe, solves the problem and I think is the correct approach of all the methods I have provided so far.

Doug

After reading through the comments, I am starting to think that this thread actually addresses two separate issues. Here's what I see:

• The original issue, along with comments #1, #2, #3, #6, the first part of #8, #10, #13 and #14, #17 all discuss a problem when creating a new node. As described in comment #13, this problem occurs only when i18n is enabled. The root cause is that i18n calls menu_get_item() which ultimately results in a node_access('create', ...) check while og_user_roles is still initializing. In other words, the permissions are checked before og_user_roles has had a chance to grant them. This suggests a problem with og_user_roles.
• A second issue, discussed in comments #4, #5, the second half of #8, #15, #16, #18, #19 and #20, talk about a problem that occurs when attempting to translate an existing node. The problem happens because the og_user_roles module needs some context to know whether or not to assign a role, and it cannot find that context unless the gids[] parameter is passed in the "add translation" link (i.e.: HTTP GET). Because I haven't looked into this problem in depth (yet), I do not know the root cause of this problem, but I suspect that og_user_roles is failing to get the context properly (since translation works fine in og).

(Note that I cannot tell exactly which one of the above issues are being discussed in comments #7, #9, #11 and #12)

While the symptoms of both issues are the same, the steps taken to reproduce the second problem are different. Additionally, the gids[] URL parameter is passed in the first issue; so I'm starting to suspect that the root causes are also different.

To solve all of this confusion, I propose the following steps. Please let me know what you think:

1. For clarity's sake, let's separate the second problem into a separate issue.
2. I have prepared some steps to reproduce the the first issue from a fresh install of Drupal. I can also write a description of the way we expect it to work and provide a stack trace. This will make it more helpful for the maintainers of this module to debug.
3. Let's change the status of this issue to "needs review" so that we let the maintainers of this module know that @wdouglascampbell's patches in #15 and #18 need be reviewed.
4. We should mark #794548: Once install i18n, OG user role stop working as a duplicate of this one and close it because it appears to be a duplicate of the first issue and the first issue's root cause appears to be with this module, not i18n.

(fulfills suggestion 2 in comment #21)

Steps to Reproduce:

1. Set up the site:
   1. Download and install Drupal 6.16
   2. Download and enable og_user_roles-6.x-4.1 (to satisfy dependencies, download og-6.x-2.1 and views-6.x-2.10). Disable any modules that are not required.
   3. Set up group and group node content types:
      1. Under Administer -> Content management -> Content types, choose Add content type, and create a new content type (in this example, the content type will be group and name will be Group), setting this content type's Organic groups usage to Group node
      2. Under Administer -> Content management -> Content types, choose Add content type, and create a new content type (in this example, the content type will be group_standardpost, and name will be Standard Post), setting this content type's Organic groups usage to Standard group post
      3. Under Administer -> Site building -> Blocks, ensure that the block named Group details is not disabled (in this example, I put it in Right sidebar).
   4. Set up roles and permissions:
      1. Under Administer -> User management -> Users, add a new user (in this example, their username will be testuser)
      2. Under Administer -> User management -> Roles, add a new role (in this example, the role will be testrole)
      3. Under Administer -> User management -> Permissions, check off the permission create group_standardpost contentfor testrole
      4. Under Administer -> Organic groups -> User roles, under Default role assignments, set the Default role for new group members to be testrole.
   5. Under Create content -> Group, create a new group (in this example, the title and description will be testgroup)
   6. Under Administer -> Content management -> Post settings, under Node access status, choose Rebuild permissions.
   7. Log out of the super-administrator (user 1)
2. Show that the configuration works with internationalization turned off:
   1. Log in as testuser
   2. Under Groups, click Join in the Join Link column of the table next to testgroup, and confirm that you want to join the group.
   3. Under Groups, click testgroup in the Group column of the table
   4. In the right sidebar, click Create Standard Post (noting that you get a standard node create form); create a new node
   5. Log out of testuser
3. Enable i18n:
   1. Log in as the super-administrator (user 1)
   2. Download i18n-6.x-1.4, and enable the Internationalization module (to satisfy dependencies, Content translation and locale also need to be enabled)
   3. Log out of the super-administrator (user 1)
4. Show that the configuration breaks with internationalization turned on:
   1. Log in as testuser
   2. Under Groups, click testgroup in the Group column of the table
   3. In the right sidebar, click Create Standard Post, and note that you get an Access Denied

Expected Functionality:

testuser should be able to add a node when internationalization is turned on.

Stack Trace

#0 [internal function]: blog_access('create', 'blog', Object(stdClass))
#1 /.../includes/module.inc(462): call_user_func_array('blog_access', Array)
#2 /.../modules/node/node.module(2033): module_invoke('blog', 'access', 'create', 'blog', Object(stdClass))
#3 [internal function]: node_access('create', 'blog')
#4 /.../includes/menu.inc(452): call_user_func_array('node_access', Array)
#5 /.../includes/menu.inc(581): _menu_check_access(Array, Array)
#6 /.../includes/menu.inc(316): _menu_translate(Array, Array)
#7 /.../includes/menu.inc(701): menu_get_item(NULL)
#8 /.../sites/default/modules/i18n/i18n.module(359): menu_get_object('node')
#9 /.../sites/default/modules/i18n/i18n.module(405): i18n_selection_mode()
#10 [internal function]: i18n_db_rewrite_sql('SELECT nt.type,...', 'nt', 'type', Array)
#11 /.../includes/module.inc(462): call_user_func_array('i18n_db_rewrite...', Array)
#12 /.../includes/database.inc(286): module_invoke('i18n', 'db_rewrite_sql', 'SELECT nt.type,...', 'nt', 'type', Array)
#13 /.../includes/database.inc(329): _db_rewrite_sql('SELECT nt.type,...', 'nt', 'type', Array)
#14 /.../modules/node/node.module(558): db_rewrite_sql('SELECT nt.type,...', 'nt', 'type')
#15 /.../modules/node/node.module(423): _node_types_build()
#16 /.../modules/node/node.module(633): node_get_types('module', Object(stdClass))
#17 /.../modules/node/node.module(653): node_hook(Object(stdClass), 'load')
#18 /.../modules/node/node.module(761): node_invoke(Object(stdClass), 'load')
#19 /.../sites/default/modules/og_user_roles/og_user_roles.module(169): node_load(1)
#20 /.../sites/default/modules/og_user_roles/og_user_roles.module(125): og_user_roles_determine_context()
#21 [internal function]: og_user_roles_init()
#22 /.../includes/module.inc(483): call_user_func_array('og_user_roles_i...', Array)
#23 /.../includes/common.inc(2622): module_invoke_all('init')
#24 /.../includes/bootstrap.inc(1080): _drupal_bootstrap_full()
#25 /.../includes/bootstrap.inc(989): _drupal_bootstrap(8)
#26 /.../index.php(16): drupal_bootstrap(8)
#27 {main}

Getting the Stack Trace
To get the stack trace, I copied the core blog module into /sites/default/modules/, and modified function blog_access($op, $node, $account) as follows:

--- blog.module.original	2009-02-25 07:21:53.000000000 -0500
+++ blog.module	2010-05-20 13:26:26.000000000 -0400
@@ -32,12 +32,25 @@ function blog_perm() {
 function blog_access($op, $node, $account) {
   switch ($op) {
     case 'create':
-      // Anonymous users cannot post even if they have the permission. 
-      return user_access('create blog entries', $account) && $account->uid ? TRUE : NULL;
+      // Anonymous users cannot post even if they have the permission.
+      // BEGIN DEBUG:
+      if(!user_access('create blog entries', $account, TRUE) && arg(0) == 'node' && arg(1) == 'add' && arg(2) == 'blog') {
+        try {
+          throw new Exception();
+        }
+        catch(Exception $e) {
+          print 'Im in ur blog_access checkin ur roles. Also, stacktrace: <pre>';
+          var_dump($e->getTraceAsString());
+          print '</pre>';
+          die();
+        }
+      }
+      // END DEBUG:
+      return user_access('create blog entries', $account, TRUE) && $account->uid ? TRUE : NULL;
     case 'update':
-      return user_access('edit any blog entry', $account) || (user_access('edit own blog entries', $account) && ($node->uid == $account->uid)) ? TRUE : NULL;
+      return user_access('edit any blog entry', $account, TRUE) || (user_access('edit own blog entries', $account) && ($node->uid == $account->uid)) ? TRUE : NULL;
     case 'delete':
-      return user_access('delete any blog entry', $account) || (user_access('delete own blog entries', $account) && ($node->uid == $account->uid)) ? TRUE : NULL;
+      return user_access('delete any blog entry', $account, TRUE) || (user_access('delete own blog entries', $account) && ($node->uid == $account->uid)) ? TRUE : NULL;
   }
 }

I then essentially followed the "Steps to Reproduce" above starting from step 1.3.2; except that I used blog instead of group_standardpost.

I chose the blog module because it's short and simple.

Notes:

I'm marking this bug as critical because it describes a problem that prevents users from adding content to a site through the normal use of this module.

Fulfilling comment #21's step 3, I am setting the status of this bug to needs review because @wdouglascampbell has submitted two patches, in #13 and #19, which need to be evaluated by the maintainers of this module.

@mparker17, thanks for adding the clarification. I hope that this gets the attention of the module maintainers soon.

Let me clarify two issues:

1. First, the only patch that needs review is the one posted in #19. The patch in #13 does not work in all cases.

2. The issue addressed by comments #7, #9, #11, #12 where are referring to the original issue of being unable to create a new node when i18n is enabled.

Fullfilling comment #21's step 1 by creating #808494: Access denied when translating node if restricted to a role assigned by og_user_roles for the node translation issue.

Subscribe

Different usage scenarii, same issues: patch #19 works great!
Thanks a lot.

Hi, I think i've found a solution.

The problem is that og_user_roles are not loaded at correct place. Them must be loaded on og_set_group_context. When you set on what group are you, is the right moment to change the roles, or not?

I've added this to og.module at line 802 and it works for me.

<?php
if (module_exists('og_user_roles')) {
    og_user_roles_grant_roles($user, $node);
}
?>

Function finally likes that:

<?php
function og_set_group_context($node = NULL, $clear = FALSE) {
  static $stored_group_node;
  global $user;
  if ($clear) {
    $stored_group_node = NULL;
  }

  if (!empty($node) && og_is_group_type($node->type)) {
    $stored_group_node = $node;
    if (module_exists('og_user_roles')) {
      og_user_roles_grant_roles($user, $node);
    }
    og_set_theme($node);
    // When setting the language, avoid doing so if we are on a node page
    // and the language of the node is different to the language of the
    // group. This covers the case when the site doesn't have a prefix for
    // the default language, particularly if the same node is posted in
    // multiple groups.
    $current_node = menu_get_object();
    if (!$current_node || (!og_is_group_type($current_node->type) && $current_node->language == $node->og_language)) {
      og_set_language($node);
    }
  }
  return !empty($stored_group_node) ? $stored_group_node : NULL;
}
?>

This change the rules and this issue is shared between og an og_user_roles as long as og does not provide a hook to do things on context change.

I'll provide a path on wednsday.

I've proposed the addition of a hook in og module to invoke other modules when setting context on http://drupal.org/node/1557250#comment-5944956 and I provided a patch for it.

This is a complementary patch for use with it, so you need both patches to solve the access to node/add/[type] page, this is not a problem with i18n module, instead is with access checks order, because roles are added to users too late.

@wdouglascampbell,

I've tested the patch in comment #13 and it seems to work well. I do not think the original bug described in this issue was related to i18n. I was experiencing this issue without i18n enabled and this patch resolved it. Thanks, Jason.

I agree with #30. Patch on comment #13 solved my issue of not applying the proper roles in the node/add/content for my custom content types.

Patch from #19 re-rolled against latest stable.

Patch from #29 rolled against latest stable.

#29 had a variable error which also carried through to #33. Fixed here and rolled against latest stable.