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

cburschka’s picture

Well, 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...

mountainash’s picture

Version: 6.x-dev » 5.1

This 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.

cburschka’s picture

That 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.

vm’s picture

Version: 5.1 » 7.x-dev

issue reported here for 7.x as well : http://drupal.org/node/508782

David_Rothstein’s picture

I 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 :)

David_Rothstein’s picture

Title: Admin theme visible at /admin, even if user can't access » Write tests for: Admin theme visible at /admin, even if user can't access
Category: bug » task

#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 :)

damien tournoud’s picture

On 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.

David_Rothstein’s picture

Hm, 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...

David_Rothstein’s picture

I 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).

EvanDonovan’s picture

catch 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?

David_Rothstein’s picture

I 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.

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.