Steps to reproduce:
- Set admin theme to some other theme; say, 'bluemarine'
- As an anon user, access /admin
Your theme will switch to bluemarine and you'll receive an access denied error. This seems like unintended behaviour.
Thanks to Scarabatwork for the bug report. :)
Comments
Comment #1
cburschkaWell, since the admin theme switches in system_init just uses arg(), it's a bit hard for it to determine whether the user actually has access to the page.
It obviously can't guess and use user_acccess('administer site configuration'), because not all /admin pages are restricted to the same users. As for the /node/add and edit pages, determining whether the user has access requires duplicating a ton of logic.
The only sensible solution would be to set the theme back to default if drupal_access_denied is called...
Comment #2
mountainash commentedThis bug also existing in Drupal 5.1. This could be considered a "security" issue as it may expose content which the standard theme may not link to.
Comment #3
cburschkaThat would be placing access control in the theme layer, a major design flaw if you ask me. If something is not meant to be seen by users, it shouldn't show up in any theme, admin theme or not. So this should be at most an aesthetic issue, not a security problem.
Comment #4
vm commentedissue reported here for 7.x as well : http://drupal.org/node/508782
Comment #5
David_Rothstein commentedI have a patch at #553944: Define hook_menu_get_item_alter() as a reliable hook that runs before the page is doomed which fixes this bug "by accident" -- I actually thought it might have been a regression which was a side effect of the patch I wrote, but since everyone here seems to agree that the existing behavior is a bug, all the better :)
Comment #6
David_Rothstein commented#553944: Define hook_menu_get_item_alter() as a reliable hook that runs before the page is doomed was committed, so this bug is now fixed.
However, I'm pretty sure we didn't write a test that covered this specific behavior, so I'm tentatively leaving it open for that :)
Comment #7
damien tournoud commentedOn the other hand, we now have another "unintended" behavior: if a user has access to some (but not all) administration page, the access denied page that he might see in the admin section will be themed with the site default theme.
Comment #8
David_Rothstein commentedHm, that's a good point - although, I would sort of argue that this is a separate bug with a different fix? In other words, if they are browsing around the admin area and get an access denied link, that's probably the fault of whoever output the link without properly checking if the current user has access to it or not.
I'm pretty sure that there are tons of places that have this problem though - for example, a bunch of hook_help() implementations throughout core blindly link to other parts of the admin interface...
Comment #9
David_Rothstein commentedI just added some thoughts to #569332: Need test to confirm there are no dead links in code about how we might be able to write some tests that check for these cases (assuming we agree that it's actually a separate bug).
Comment #10
EvanDonovan commentedcatch says #596574: Admin Theme triggered even when access denied (for 6.x) is a duplicate of this issue. I'd like to get that one resolved, so what's the best way forward?
Comment #11
David_Rothstein commentedI think this is totally fixed for Drupal 7. (Even the issue Damien raised in #7 is now no longer a problem, because the "view the administration theme" permission controls whether or not an admin page will be displayed in the administration theme. Therefore, regular users browsing to an admin/* page they don't have access to will see it in the default theme, and administrators will see it in the admin theme - I just confirmed now that works.)
So it seems reasonable to keep the other issue open for 6.x. Not sure there will be any way to solve it in Drupal 6, though.