Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
Accessing https://localize.drupal.org/translate/languages/fr/export is denied, even for a connected user with permissions on the French group.
The same issue probably occurs with other languages.
Comment | File | Size | Author |
---|---|---|---|
#38 | Access denied | Translations 2013-07-27 11-14-02.png | 50.37 KB | Jose Reyero |
#37 | Access denied | Translations 2013-07-27 10-47-00.png | 62.95 KB | Jose Reyero |
#4 | 2011742-export-access-denied.png | 92.99 KB | amerkelijn |
Comments
Comment #1
zirvap CreditAttribution: zirvap commentedYes, same issue for nb, nn, and se (the ones I'm a member of).
Comment #2
Gábor HojtsyMarked #2014311: I'm denied access to the Export page as duplicate.
Comment #3
Gábor HojtsyAre 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?
Comment #4
amerkelijn CreditAttribution: amerkelijn commentedI'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.
Comment #5
amerkelijn CreditAttribution: amerkelijn commentedI didn't use any GET arguments. The URL was just https://localize.drupal.org/translate/languages/nl/export
Comment #6
philipz CreditAttribution: philipz commentedI have the same problem in polish language - both export and import tabs.
Comment #7
droplet CreditAttribution: droplet commentedin LDO project, this is critical.
We can't EXPORT thousands suggestion and translation templates & IMPORT .po files
Comment #8
Pomliane CreditAttribution: Pomliane commentedSome contributors ask me how they can import their suggestions in ldo; do you know if there are any alternate ways to import/export strings to/from ldo?
Comment #9
droplet CreditAttribution: droplet commented@Pomliane,
Right now, no way :(
Comment #10
aalamaki CreditAttribution: aalamaki commentedAny 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.
Comment #11
MegaChriz CreditAttribution: MegaChriz commentedI 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.
Comment #12
droplet CreditAttribution: droplet commentedLocalization client only able to submit string one by one. (unless it changed recently)
Comment #13
droplet CreditAttribution: droplet commentedAnyone working on it? Or anything we can help to move it forward?
Thanks.
Comment #14
philipz CreditAttribution: philipz commentedThis 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?
Comment #15
aalamaki CreditAttribution: aalamaki commentedMmm, no clue what is causing it...managed to translate D8 alpha2 to finnish though, just a shame no-one can export it currently...
Comment #16
Gábor HojtsyThe 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:
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.
Comment #17
aalamaki CreditAttribution: aalamaki commentedMmm, 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.
Comment #18
Gábor HojtsyIn terms of how the user role lands on the user, we use the og_user_roles module, with this code relevant:
The relevant code in l10n_groups to figure out the group role:
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:
Comment #19
aalamaki CreditAttribution: aalamaki commentedMmm,
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...
Comment #20
Gábor HojtsyYeah, 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.
Comment #21
aalamaki CreditAttribution: aalamaki commentedHmm,
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
Comment #22
Gábor Hojtsyog 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? :)
Comment #23
aalamaki CreditAttribution: aalamaki commentedHi,
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 :)
Comment #24
Gábor HojtsyCheck years on the posts not only months :D
Comment #25
aalamaki CreditAttribution: aalamaki commentedLOL...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...
Comment #26
aalamaki CreditAttribution: aalamaki commentedHmm,
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... :)
Comment #27
Gábor Hojtsy@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).
Comment #28
aalamaki CreditAttribution: aalamaki commentedHi,
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.
Comment #29
droplet CreditAttribution: droplet commentedHave you ever tried to trace down to see what part blocked the access ?
Comment #30
SebCorbin CreditAttribution: SebCorbin commentedYup, but it's difficult without tools like xdebug. Basically I found out that the access callback is called before the grants are given
Comment #31
aalamaki CreditAttribution: aalamaki commented@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.
Comment #32
Gábor HojtsyNo?! See our extensive discussion above about per-group permissions.
Comment #33
aalamaki CreditAttribution: aalamaki commentedHmm 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.
Comment #34
Gábor HojtsyThe 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.
Comment #35
aalamaki CreditAttribution: aalamaki commentedHmm,
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.
Comment #36
MegaChriz CreditAttribution: MegaChriz commentedSince 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 oftranslate/languages/%l10n_community_language/import
andtranslate/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.
Comment #37
Jose Reyero CreditAttribution: Jose Reyero commentedAttaching 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..
Comment #38
Jose Reyero CreditAttribution: Jose Reyero commentedAnd 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).
Comment #39
Gábor HojtsyYeah, group admins get edit rights on content in their group. That makes the two tabs appear.
Comment #40
GoofyX CreditAttribution: GoofyX commentedHow 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.
Comment #41
aalamaki CreditAttribution: aalamaki commentedGoofyX, 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.
Comment #42
droplet CreditAttribution: droplet commentedI don't think we can discuss a buggy problem without the code. Maybe share us the 100% real codebase that used in LDO?
Comment #43
podarokI`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
Comment #44
Gábor Hojtsy@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.
Comment #45
MegaChriz CreditAttribution: MegaChriz commentedI 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 beforeog_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):
Granted authenticated user these permissions:
Created a role called 'editor' with these permissions:
Other things I did:
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 beforel10n_groups_init()
. The import/export tabs weren't shown at all when the group context couldn't be determined by og_user_roles.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()
insidedrupal_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 ofog_user_roles_init()
function revealed the following:og_user_roles_init()
was called before permissions were checked for 'import gettext files' and 'export gettext templates and translations'.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
:The following backtrace was printed when visiting the Import page as an authenticated user:
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:
og_set_group_context()
.Comment #46
SebCorbin CreditAttribution: SebCorbin commented#45 is right, reproduced the same behavior on a dev VM.
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
Comment #47
SebCorbin CreditAttribution: SebCorbin commentedThis is the issue causing this #998642: Don't run og_set_language() when viewing a node with a different language
Comment #48
SebCorbin CreditAttribution: SebCorbin commentedPatch applied from the other issue, you should be able to access these tabs now
Comment #49
MegaChriz CreditAttribution: MegaChriz commentedI 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.
Comment #50
Jose Reyero CreditAttribution: Jose Reyero commentedYes, it works! Thanks!
Comment #51
philipz CreditAttribution: philipz commentedDefinitely looks like it's working now. Thanks for fixing it!
Comment #52
droplet CreditAttribution: droplet commentedGreat! Thanks
Comment #53
Gábor HojtsyYay SebCorbin! Thanks all for the help debugging and your patience!
Comment #54
aalamaki CreditAttribution: aalamaki commentedYay...power of the community, glad this got solved... :P