Problem/Motivation
When enabling the 'Account Administration Pages' language negotiator for interface language, the Toolbar module throws an 'Access Denied' when trying to load the cached subtrees.
Steps to reproduce
- Install a standard installation (drush si)
- Do NOT disable caching in for example settings.local.php
- Enable content translation and interface translation
- enable Spanish and English
- Set language negotiation as follows:
- Set preferred administration language of user 1 to english.
- Create an article and view the full node
- Navigate to the same page but in 'Spanish' using the language switcher or just adding 'es' to the url. Should be [localhost]/es/node/1
The toolbar breaks, because of a 403 on an ajax request to load the subtrees. The browser will show the following error:
POST http://localhost/devdays/toolbar/subtrees/nAMBTIOqWe13vT5ZIhj_JroJ1d-FcDGfVKyhzq6wpFA?_wrapper_format=drupal_ajax 403 (Forbidden)
The problem has to do with the fact that the hashes for the cached subtree and the requested subtree don't coincide and therefore return a 403. See
ToolbarController::checkSubTreeAccess()
We have to find out whether this problem lies with the language negotiator for Account administration pages (and possibly other ones too, haven't tested...) or with the Toolbar module.
Proposed resolution
-
Remaining tasks
-
Comment | File | Size | Author |
---|---|---|---|
#22 | 2868193-22.patch | 873 bytes | idflood |
| |||
#10 | 2868193-10.patch | 865 bytes | casey |
#4 | Selection_043.png | 130.96 KB | nuez |
#4 | Selection_042.png | 21.51 KB | nuez |
Comments
Comment #2
nuezComment #3
tar_inet CreditAttribution: tar_inet as a volunteer commentedI have followed all the steps and I can´t reproduce it. May I missing something? How do you get this error? Just loading the page? I can't see any error on the toolbar.
Comment #4
nuezComment #5
nuezI've checked it again and the issue still appears with the latest 8.4.x.
I've updated the steps with images to make it clearer. Please let us know if you can reproduce it.
Comment #6
kjauslin CreditAttribution: kjauslin commentedI can also see this problem, using 8.3.0. Having "Account administration pages" activated at the language detection page at /admin/config/regional/language/detection. When de-activating the "Account administration pages" setting, the ajax seems to work again. I also have the primary language setting at something different than English.
Comment #7
rferguson CreditAttribution: rferguson commentedI'm also having this issue when that setting is enabled. Logged in or not, I can't visit my french content pages. I just get page not found.
Comment #9
casey CreditAttribution: casey at SWIS commentedComment #10
casey CreditAttribution: casey at SWIS commentedComment #11
nuezI'm not sure if disabling the router access checks is the right approach, I think it would be better to find out the exact root of the problem by writing a test.
Comment #12
nuezComment #13
nuezThe problem seems to be related to fact that the subtree rendered in two different places and checked if they’re still the exact same subtree with a hash. Once the subtree is generated with the page request, and another via ajax calling ‘/toolbar/subtrees/{hash}’.
The hash of both instances of the subtree needs to be compared, and if they don’t coincide there is a 403 on ‘toolbar/subtrees/{hash}’. I’ve found incorrect 403 statuses in at least 2 occasions:
The preferred language for administration pages of the user is english, the content language of a non-admin page is say Spanish. Then the toolbar subtree will render Spanish in the DOM but in english in /toolbar/subtrees/{hash}, causing a 403.
It also seems to occur when cache is switched on and the user switches to a language for which no previous cached subtree has been rendered. (I still have to further investigate this problem).
Solution: Make sure that language of the /toolbar/subtree/{hash} path is negotiated in the same way as the page where the toolbar is coming from.
Next step: Write a test to reproduce the issue.
Comment #16
candelas CreditAttribution: candelas commentedHaving the same problem.
@nuez would you have a moment to make the test, please? Thanks
Comment #17
rwam CreditAttribution: rwam commentedPatch in #10 has no effects and doesn't solve the problem for our sites. We're using content and interface translation too, but we get always an 403.
For now, I remove the check if the hashes are equals to provide a working toolbar menu on
ToolbarController::checkSubTreeAccess()
:May be it relates to this bug, but on the horizontal bar the active trail isn't working.
And I would change priority to Major because the backend is unusable with vertical toolbar.
Comment #18
rwam CreditAttribution: rwam commentedPossible duplicate of Toolbar submenu 403 forbidden when using different user language and relates to Admin toolbar should always be rendered in the admin language (if set).
Comment #22
idflood CreditAttribution: idflood at Stimul.ch commentedWhile it's not the correct solution the patch was still a good workaround for our use case. The patch didn't apply anymore on 8.9.* so here is a reroll.
Comment #24
smulvih2#22 works for me on 8.8.10
Comment #26
Rar9 CreditAttribution: Rar9 commentedhi i applied patch 22, but I still get above issue sometimes
D9.1.10
Lang DE as default + eng + Account administration pages
Path: /en/toolbar/subtrees/kEIgVbrAnk8tVlQ2I7zujQnIh9zFpVDT4RPSO9jovOs?_wrapper_format=drupal_ajax. Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 120 of /var/www/vhosts/drupal9/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).
Comment #28
sonneworks CreditAttribution: sonneworks commentedtried patch 22, did not work.
Found out that the _toolbar_get_subtrees_hash() produces a different hash because the initial toolbar_get_rendered_subtrees() contained the "scheduled content" from the scheduler module and the menu generated when doing the ajax request did not contain the scheduled content item. Not sure why, i've disabled the view and the problem was no longer present
not a solution but at least i can continue for now
Comment #32
jordan.jamous CreditAttribution: jordan.jamous at Eighty Options commentedProblem still exists in Drupal 10.1.4, has anyone found a solution for this matter? #22 did't work for me. My setup is similar to the setup explained in the issue description. Thanks
Comment #33
tvalimaa CreditAttribution: tvalimaa commentedI have the same problem with same kind of settings and Drupal 10.1.4. #22 patch didn't work.
What I debug toolbar modules code I find that ToolbarController.php
checkSubTreeAccess()
function $hash and $expected_hash are not match so hash_equals() returns false.Comment #34
candelas CreditAttribution: candelas commentedI have the same problem with same kind of settings and Drupal 10.2.1 .
I have Catalan as main language and I as user English (I am user 1).
My solution is not to use admin language in the language negotiation and set first user and then url as the only Detection methods.