Access to "Import / Export" tab denied

The same issue probably occurs with other languages.

Yes, same issue for nb, nn, and se (the ones I'm a member of).

Marked #2014311: I'm denied access to the Export page as duplicate.

Are you getting a Drupal access denied or a server access denied (does it look like using the site theme)?

Also, if you remove all GET arguments from the URL (everything after the ? and including the ?), does it still get you a 404?

I'm also getting an access denied when I go to https://localize.drupal.org/translate/languages/nl/export, though I'm a member of the Dutch team. It is a Drupal access denied for me. See also the attached image.

Also, if you remove all GET arguments from the URL (everything after the ? and including the ?), does it still get you a 404?

I didn't use any GET arguments. The URL was just https://localize.drupal.org/translate/languages/nl/export

I have the same problem in polish language - both export and import tabs.

in LDO project, this is critical.

We can't EXPORT thousands suggestion and translation templates & IMPORT .po files

@Pomliane,
Right now, no way :(

Any solution to this? I'm group admin for the finnish translation team and getting the same...tried looking thru the settings, nothing there that could be changed.

I also have no access to the import and export tabs.

An alternative to import suggestions in ldo would perhaps be the Localization client module. That module can submit translations to localize.drupal.org. I have not tested if this still works now that I get access denied to the import/export tab.

Exporting translations with suggestions would be a little harder. Perhaps this is possible with code from Localization update, as that module is capable of pulling translations of localize.drupal.org.

Localization client only able to submit string one by one. (unless it changed recently)

Anyone working on it? Or anything we can help to move it forward?

Thanks.

This issue is getting really critical as Drupal 8 translation nears. Isn't this caused by some fixes related to recent security problems on drupal.org?

Mmm, no clue what is causing it...managed to translate D8 alpha2 to finnish though, just a shame no-one can export it currently...

The translations are regularly exported to http://ftp.drupal.org/files/translations/8.x/drupal/ (and there are some updated as late as yesterday and today), so that it cannot be exported is not true :) Direct links to those files are available in a nice overview table format on languages pages, eg. https://localize.drupal.org/translate/languages/hu (shows alpha2 translation pre-exported on the 15th yesterday).

I see the pain this issue have caused but I have not seen any indication as to what may cause it. I cross-checked permissions for the export/import ("export gettext templates and translations" and "import gettext files" are both granted to regular team members) and have not found issues. Given that its a Drupal error, and not a server error, I suspect some module update caused it. It may be related to how we get OG group membership information or how we don't get it rather when we check permissions there. Here are the access checks on the import/export tabs:

  $items['translate/languages/%l10n_community_language/import'] = array(
    'title' => 'Import',
    'page callback' => 'l10n_community_import_page',
    'page arguments' => array(2),
    'file' => 'import.inc',
    'access callback' => 'user_access',
    'access arguments' => array('import gettext files'),
    'type' => MENU_LOCAL_TASK,
    'weight' => -5,
  );
  $items['translate/languages/%l10n_community_language/export'] = array(
    'title' => 'Export',
    'page callback' => 'l10n_community_export_page',
    'page arguments' => array(NULL, 2),
    'file' => 'export.inc',
    'access callback' => 'user_access',
    'access arguments' => array('export gettext templates and translations'),
    'type' => MENU_LOCAL_TASK,
    'weight' => 0,
  );

We only grant these two permissions to mebmers of groups in their group. So random people cannot import random things (likely bad stuff) into your translations, and team leads have some control over permissions. So this is reliant on the group membership roles in og_user_roles added to the user before the menu access check runs. That used to be true.

Mmm, yeah u are actually correct, forgot about the pre-exported stuff and didn't realize that they are all indeed available at the ftp :)

About the permissions, one thing could be if you have a staging environment, just dsm out the user profile and og-related stuff for that user when accessing the export functionality to see if the roles are set.

Another thing that would cross my mind is the module priority; could try setting the og-related modules to have weight like -1000 in the system table to make sure they get executed first.

In terms of how the user role lands on the user, we use the og_user_roles module, with this code relevant:

function og_user_roles_init() {
  global $user;

  // Try to determine group context using customized menu system functions.
  $group_node = og_user_roles_determine_context();

  // If no group context could be determined, additionally check for a custom
  // group context that might have been set via og_set_group_context() to allow
  // for usage of extended context support in organic groups. Only modules that
  // set a context before og_user_roles_init() runs will have an effect. Since
  // og_user_roles module sets its weight to -1, other modules may have to align
  // their module weights to be able to set a custom group context early enough.
  if (!isset($group_node)) {
    $group_node = og_get_group_context();
  }

  // Assign additional user roles to current user (if any).
  og_user_roles_grant_roles($user, $group_node);
}

The relevant code in l10n_groups to figure out the group role:

/**
 * Implementation of hook_init().
 *
 * Tell organic groups we are on a group page if under a group's area
 * on the translation pages.
 */
function l10n_groups_init() {
  if (user_access('access localization community') && (arg(0) == 'translate') && in_array(arg(1), array('languages', 'details', 'suggestions', 'approve', 'decline')) && ($langcode = arg(2))) {
    // If under a localization path URL for a language, set context.
    if (!empty($langcode)) {
      l10n_groups_set_context($langcode);
    }
  }

  //...
}


/**
 * Set group context to the group determined by $langcode.
 */
function l10n_groups_set_context($langcode) {
  $groups = l10n_groups_get_groups();
  if (isset($groups[$langcode])) {
    // Set group context and ask for og details block.
    $node = node_load($groups[$langcode]);
    og_set_group_context($node);
  }
}

Finally, we also ensure the l10n_groups one runs before the og_user_roles one, so the context should be properly set for og_user_roles:

mysql> select name, weight from system where name in ('og', 'og_user_roles', 'l10n_groups');
+---------------+--------+
| name          | weight |
+---------------+--------+
| l10n_groups   |     -2 | 
| og            |      0 | 
| og_user_roles |     -1 | 
+---------------+--------+
3 rows in set (0.00 sec)

Mmm,

In the menu hook, you are setting:

'access arguments' => array('export gettext templates and translations'),

Then in the l10n_groups_init(), you have that if for user_access but you are not checking for that permission there, could that be the problem?

Also, are there any custom access modules or rules enabled that could override the permissions?

Btw, another funny thing, I'm seeing the Edit and Revisions tabs in the page eg. https://localize.drupal.org/translate/languages/fi/export but it's giving me the same "you need to sign in" when clicking on them...

Yeah, so the way we structure permissions (and this worked for years without interruption :) is that all logged in users get 'access localization community'. Then when people become group members they get the import and export perms via their group specific role assigned. This is where og_user_roles, og and l10n_groups works together to make Drupal aware of that context specific role early enough so that it can grant access to members. We cannot just set it wider because it would let people who should not have credentials import random stuff.

Hmm,

Ok what about checking if og got updated in the last updates before the issue started? Cause like u said, this smells like a OG problem of how it gets the permissions...

Wouldn't fix the issue but if you have a staging environment, could try rollback of OG-related modules (and perhaps even d-core) to see if it's a conflict of some sort...that would at least narrow down the issue and help tracking where it goes wrong. Then when the module that causes the issue has been tracked down, do a diff and see what changed in it...should give a fairly good idea of what's wrong

og is from last June, og user roles is from 2010(!) March, both running latest versions. I don't have a good handle on the current staging process unfortunately, so did not yet got around to trying out instrumenting the code there. I can reproduce the bug with a test user for sure. I hope this provided good insight for @sebcorbin to maybe look? :)

Hi,

Ya hope so, checked release notes for the latest OG...got a small hunch that https://drupal.org/node/1619810 which was included in it might be the problem but a diff between the last two OG versions should tell a bit more.

However, the latest version of OG was posted on June 6th whereas the issue with the export was posted here already on the June 3rd so unless the some patch was applied before that to fix the vulnerability, it seems strange that it could be the problem. Could, however, have a look and make sure that the OG Groups is still compatible with latest OG.

Another thing to check is the other module updates and specifically, have there been updates related to permission handling in the core? If so, perhaps rollback...though core issues most likely would have popped up also elsewhere :)

Check years on the posts not only months :D

LOL...u're correct, my bad :) I read above that u said the OG release in use is from last June so checked the release notes for the latest stable D6 version of OG which is from June 6th, didn't realize the year was 2012.

Anyways that spoils the theory of the problem being at least directly OG related...should perhaps check other module updates then. The core too is from last January with some security fixes but unless the issue started already back then, I doubt that's the problem.

Guessing (if possible), check logs on when the problem started and check what modules updated recently before it started...this sort of issues don't come up on its own that's for sure :)

Just another thing that crossed my mind, is localize.drupal.org syncing/fetching group or user data from drupal.org, could that sort of a issue be the problem? Also, has there been updates on stuff like varnish or php installations on the localize.drupal.org? One thing to try (probably been already tested), cache clear...

Hmm,

Also the pre-exported file seems to have some issues, it is missing strings; for example https://localize.drupal.org/translate/languages/fi/translate?sid=1732993 has a translation but when installing D8 alpha-2 with finnish language, that string is missing translation.

That's just an example, there are plenty of others as well...checked the translation .po and the entire string is not there at all, not even the source. Guessing it should be cause the translation was added already 07/05/2013 and is marked as accepted like it should be as I'm an admin of the group... :)

@aalamaki: are you *manually* importing the alpha2 translation to Drupal 8 or you just assume the automated import will do it? (Also it may not be a good idea to have side discussions like this on a critical issue).

Hi,

Ok you are right, I started a new issue at https://drupal.org/node/2043877. That one is kind of related to the importing/exporting though cause some strings that have been already translated are missing and some translatable strings are missing on localize.drupal.org.

This might lead to duplicate work for someone who is translating the D8 so in that sence should be addressed as well.

Have you ever tried to trace down to see what part blocked the access ?

Yup, but it's difficult without tools like xdebug. Basically I found out that the access callback is called before the grants are given

@SebCorbin, aren't all the privileges granted already in the login phrase when user authenticates to the site? Did you try printing out a test user profile with eg. dsm to see what privileges and groups the user has after login?

That should tell a bit more, the menu hooks should then execute on basis of those given permissions and grant/deny access accordingly; on basis of what Gábor pasted earlier it seems to be the case. If no other modules got updated, what crosses my mind is the chance of some sort of a session problem, perhaps due to changes in caching on the server side...

Also was thinking of another thing (pretty far-fetched but still), does the l10n_groups get fired after user authenticates? If not, could try playing with the module weights one more time.

aren't all the privileges granted already in the login phrase when user authenticates to the site?

No?! See our extensive discussion above about per-group permissions.

Hmm yes...I understand what you mean but I thought in Drupal the access privileges get loaded when the user authenticates. What happens in the l10n_groups and what access is granted on basis of the groups is another thing but I thought that also og groups should get loaded when the user session is set.

The roles can be different per group, that is what og_user_roles does, and that is what seems to be failing here. However, even access of the translation submission UI is governed by this process, so its pretty special that only the import and export ones fail.

Hmm,

Yes indeed...but it's not just the import/export failing. When I click the "Export" tab, it takes to the access denied page. On that, on top, there are the Edit and Revision tabs, they are visible to me at least but clicking on them gives the same access denied.

Since the tabs 'Import' and 'Export' are shown on several pages of the translation team I'm member of, I intend to believe that the access denied is caused by a direct call to drupal_access_denied() somewhere. The menu access callbacks of translate/languages/%l10n_community_language/import and translate/languages/%l10n_community_language/export should return TRUE, as the tabs are shown.

I've made an overview of several pages I visited and tried to find other pages that lead to an access denied page. I tried to visit pages of a team I'm a member of (Dutch team) and of a team I'm no member of (German team). Hopefully, this may give an idea of where the cause of the problem may lie. So far, only the import and export pages seem to give unexpected results.

One thing I noticed was that on the import/export pages of the Dutch team (member) I saw the tabs 'View' and 'Revisions' (which both lead to a Drupal access denied page), but on the import/export pages of the German team (not member) I did *not* see this tabs, but just a Drupal access denied page.

Dutch team pages

I'm a member of the Dutch team.

German team pages

I'm not a member of the German team.

Attaching screenshot if it's any help.

Note user is looged in (I'm the group administrator) and also the 'Edit' and 'Revisions' tabs (that cause access denied too) but I guess they shouldn't be visible..

And the second part, screenshot of the same page for a group I don't belong to.

The interesting thing: same page but without 'Edit' and 'Revisions' tab, which makes me think that somehow the user gets the group credentials/permissions late, after the page has been 'decided' (access denied) but before it is rendered (local tasks are rendered).

Yeah, group admins get edit rights on content in their group. That makes the two tabs appear.

How often are translations generated in https://localize.drupal.org/translate/downloads? I mean, I just translated a small module (insert) in Greek, but I cannot export the translations, because of this bug. However, the page in the link above should provide downloads to the translation, but how often do these get generated? I downloaded the translation for this module, but it consists of 5-6 strings only, which is obviously not correct.

GoofyX, which translation did you try to download? I just checked http://ftp.drupal.org/files/translations/7.x/insert/insert-7.x-1.3.el.po and in it all the strings seem to appear with a translation; the file is marked as generated today.

I don't think we can discuss a buggy problem without the code. Maybe share us the 100% real codebase that used in LDO?

I`m ru, uk, be groups manager and
https://localize.drupal.org/translate/languages/ru/export
https://localize.drupal.org/translate/languages/uk/export
https://localize.drupal.org/translate/languages/be/export

Access denied

@droplet: there are no secrets :) localize.drupal.org runs the following:

- drupal 6.28
- l10n_server 6.x-3.0-beta1+25-dev
- og 6.x-2.4
- og user roles 6.x-4.1

I think these are the relevant ones.

I reproduced the problem

I've tried to set this up locally and I've been able to reproduce the problem! I had to set the weight of the l10n_groups module manually to -2 though, as I found out that l10n_groups_init() needed to be executed before og_user_roles_init() and og_user_roles has a module weight of -1. l10n_groups_init() sets the group context that og_user_roles needs to know to temporary assign the user a specific role.

Enabled modules (among others):

• Localization community UI
• Localization groups
• Localization packager
• Localization server
• Localization server for Gettext files
• Organic groups
• Organic groups user roles
• Organic groups Views integration

Granted authenticated user these permissions:

• access localization community
• browse translations

Created a role called 'editor' with these permissions:

• export gettext templates and translations
• import gettext files
• submit suggestions

Other things I did:

1. On admin/og/og_user_roles, set the role 'editor' to be a Translation group role and made it the default for new group members.
2. Added two languages at admin/settings/language
3. Created a translation group node for each new language, all set to the default settings except for 'Default role for new members' which was set to 'editor'.
4. Set the weight of the l10n_groups module manually to -2.
   This was needed because og_user_roles had a weight of -1 and og_user_roles wasn't able to detect the group context if og_user_roles_init() was executed before l10n_groups_init(). The import/export tabs weren't shown at all when the group context couldn't be determined by og_user_roles.
5. Logged in as an authenticated user and became a member of one of the translation groups.

As an authenticated user I could see the import/export tabs, but when clicking on them I got an access denied, just as on localize.drupal.org.

Debug information

To debug the problem, I wrote the contents of all variables to a log file at certain places because a debug_backtrace() inside drupal_access_denied() revealed nothing. There was only one line in the backtrace. It seemed as if the function was called directly by index.php.
Placing a pointer at the end of the user_access() function and another at the end of og_user_roles_init() function revealed the following:

• On the pages 'Overview', 'Board' and 'Translate' og_user_roles_init() was called before permissions were checked for 'import gettext files' and 'export gettext templates and translations'.
• On the pages 'Import' and 'Export' this was the opposite. For example, on the 'Import' page, permissions were checked for 'import gettext files' before og_user_roles_init() was called.

This reveals why the import/export tabs are shown, but you still get an access denied on these pages.

I putted the following code inside the user_access() function:

if ($string == 'import gettext files') {
  print '<pre>';
  debug_print_backtrace();
  die();
}

The following backtrace was printed when visiting the Import page as an authenticated user:

#0  user_access(import gettext files) called at [/Websites/drupal/drupalsites/drupal6/includes/menu.inc:451]
#1  _menu_check_access(Array ([path] => translate/languages/%/import,[load_functions] => Array ([2] => l10n_community_language_load),[to_arg_functions] => ,[access_callback] => user_access,[access_arguments] => a:1:{i:0;s:20:"import gettext files";},[page_callback] => l10n_community_import_page,[page_arguments] => a:1:{i:0;i:2;},[fit] => 13,[number_parts] => 4,[tab_parent] => translate/languages/%,[tab_root] => translate/languages/%,[title] => Import,[title_callback] => t,[title_arguments] => ,[type] => 128,[block_callback] => ,[description] => ,[position] => ,[weight] => -5,[file] => sites/all/modules/contrib/l10n_server/l10n_community/import.inc,[href] => translate/languages/nl/import,[options] => Array ()), Array ([0] => translate,[1] => languages,[2] => nl,[3] => import)) called at [/Websites/drupal/drupalsites/drupal6/includes/menu.inc:583]
#2  _menu_translate(Array ([path] => translate/languages/%/import,[load_functions] => Array ([2] => l10n_community_language_load),[to_arg_functions] => ,[access_callback] => user_access,[access_arguments] => a:1:{i:0;s:20:"import gettext files";},[page_callback] => l10n_community_import_page,[page_arguments] => a:1:{i:0;i:2;},[fit] => 13,[number_parts] => 4,[tab_parent] => translate/languages/%,[tab_root] => translate/languages/%,[title] => Import,[title_callback] => t,[title_arguments] => ,[type] => 128,[block_callback] => ,[description] => ,[position] => ,[weight] => -5,[file] => sites/all/modules/contrib/l10n_server/l10n_community/import.inc,[href] => translate/languages/nl/import,[options] => Array ()), Array ([0] => translate,[1] => languages,[2] => nl,[3] => import)) called at [/Websites/drupal/drupalsites/drupal6/includes/menu.inc:318]
#3  menu_get_item() called at [/Websites/drupal/drupalsites/drupal6/includes/menu.inc:703]
#4  menu_get_object() called at [/Websites/drupal/drupalsites/drupal6/sites/all/modules/contrib/og/og.module:808]
#5  og_set_group_context(stdClass Object ([nid] => 1,[type] => l10n_group,[language] => en,[uid] => 1,[status] => 1,[created] => 1377025737,[changed] => 1377026702,[comment] => 2,[promote] => 1,[moderate] => 0,[sticky] => 0,[tnid] => 0,[translate] => 0,[vid] => 1,[revision_uid] => 1,[title] => Dutch,[body] => ,[teaser] => ,[log] => ,[revision_timestamp] => 1377026702,[format] => 1,[name] => drupal,[picture] => ,[data] => a:0:{},[l10n_group_language] => nl,[og_user_roles_default_role] => 4,[path] => dutch,[og_selective] => 0,[og_description] => Vertalen naar het Nederlands,[og_theme] => ,[og_register] => 0,[og_directory] => 1,[og_language] => nl,[og_private] => 0,[last_comment_timestamp] => 1377025737,[last_comment_name] => ,[comment_count] => 0,[taxonomy] => Array ())) called at [/Websites/drupal/drupalsites/drupal6/sites/all/modules/contrib/l10n_server/l10n_groups/l10n_groups.module:97]
#6  l10n_groups_set_context(nl) called at [/Websites/drupal/drupalsites/drupal6/sites/all/modules/contrib/l10n_server/l10n_groups/l10n_groups.module:76]
#7  l10n_groups_init()
#8  call_user_func_array(l10n_groups_init, Array ()) called at [/Websites/drupal/drupalsites/drupal6/includes/module.inc:497]
#9  module_invoke_all(init) called at [/Websites/drupal/drupalsites/drupal6/includes/common.inc:2730]
#10 _drupal_bootstrap_full() called at [/Websites/drupal/drupalsites/drupal6/includes/bootstrap.inc:1206]
#11 _drupal_bootstrap(8) called at [/Websites/drupal/drupalsites/drupal6/includes/bootstrap.inc:1113]
#12 drupal_bootstrap(8) called at [/Websites/drupal/drupalsites/drupal6/index.php:15]

So, appearantly, when calling og_set_group_context(), the menu item is retrieved. This will cause the permission check for 'import gettext files' to be cached (static), but the og_user_roles module succesfully flushes the permission checks static cache shortly after. Though the permission for 'import gettext files' isn't rechecked later. So I guess the problem has something to do with menu (static) caching.

Summary

On a local setup:

• The import/export tabs weren't shown at all until I set the module weight of l10n_groups to -2.
• On pages 'Overview', 'Board' and 'Translate' the permission check for 'import gettext files' was done after og_user_roles temporary assigned a role.
• On page 'Import' the permission check for 'import gettext files' was done before og_user_roles temporary assigned a role. The permission check wasn't done later again.
• I suspect the problem might have something to do with menu (static) caching; the menu-item is retrieved inside og_set_group_context().

#45 is right, reproduced the same behavior on a dev VM.

1. l10n_groups_init() is called, due to its weight of -2
2. og_set_group_context() calls menu_get_item() which fills the static cache for router_item
3. in _menu_check_access(): user_access('import gettext files') is called (without group roles) and put to static cache in parent function menu_get_item()
4. og_user_roles_init() is called, due to its weight of -1
5. flushing user_access() static so that roles are populated but router_item['access'] is already cached

I'm hitting a wall, since it's impossible in D6 to flush another function's static cache. But still, I don't understand why this appeared recently after updating drupal core, will look into that...

Best way to fix this: upgrade to D7

This is the issue causing this #998642: Don't run og_set_language() when viewing a node with a different language

Patch applied from the other issue, you should be able to access these tabs now

I was about to propose to apply the patch from that other issue (after I would have tried it). Great it has been fixed.
I can confirm that I now have access again to the import/export pages of language groups I'm a member of.

Yes, it works! Thanks!

Definitely looks like it's working now. Thanks for fixing it!

Great! Thanks

Yay SebCorbin! Thanks all for the help debugging and your patience!

Yay...power of the community, glad this got solved... :P