Admin Theme triggered even when access denied

I have the same issue on Admin 1.0-beta3: the Admin theme loads even if access is denied. Furthermore, sometimes the theme doesn't load fully. The CSS for it may not show up at all. (Note: I have Boost enabled also, but it shouldn't be caching any pages under /admin.)

CORRECTION: It seems like the basic CSS for Access Denied pages loads but the CSS for the Slate theme doesn't show up. I will continue to look into this...

In my case, I simply changed the conditional for initializing the Slate theme to the following:

else if (arg(0) == 'admin' && variable_get('admin_theme', 'slate') == 'slate' && user_access('access administration pages')) {

The last part ensures that the Slate theme only shows up for administrators on my site. (Note that if you have people who can do administrative tasks but who don't have that permission, you may need to use a different one.)

I believe this issue shouldn't exist in the 2.0 version of Admin, since that version doesn't use this hack. Is the 2.0 version ready to be used in production yet?

Actually, I determined that it was better to have else if (arg(0) == 'admin' && variable_get('admin_theme', 'slate') == 'slate') {. Without the additional conditional, there is no theme initialized at all, but the "bad" CSS & JS does not get cached when you log in.

I would like to see a branch of Admin module that used the architecture of the 2.x branch, but the UX and design of the Slate theme from the 1.x branch. I find it much more usable than the 2.x branch, which has the same problems as the Admin_Menu module when you have a large number of modules enabled.

This is a bug in core -- I can reproduce it on a fresh D6 with no contrib modules at all.

I am upping this to critical, as this can lead to anonymous or non-authorized users accessing private information.

Example: a site admin enables in his admin theme a block with information meant only for admin, with the intention that since only admins can see admin pages, this will be private. A good example from core is the 'Who's online' block.
Because of this bug, non-authorized users can see this if they go to any admin page.

@joachim: blocks have access checking on their own and are not connected to the page access checking. This is not only applicable to admin pages but all pages in Drupal. If you don't want to show certain blocks to certain people then you can configure the block as such.

In general, Drupal does not have an "error page theme" setting, not even a "maintenance theme" setting. You can install modules to achieve some of this behavior, but generally Drupal just uses the theme to be used for the page in case of errors. This limitation applies in the same way to D7. If you'd like to see settings introduced for this, D7 is the place to ask.

Subscribe. Just noticed, and it scares me a slight bit.

This was fixed in Drupal 7. And is a duplicate of either #137198: Write tests for: Admin theme visible at /admin, even if user can't access or #553944: Define hook_menu_get_item_alter() as a reliable hook that runs before the page is doomed, the latter is not backportable to 6, the former doesn't have a patc. Moving this back to the D6 queue. Also it's not critical.

maybe there is a workaround, by using the "sections" module:
http://drupal.org/project/sections

- when sections is enabled, a new admin-section is added by default
- just make sure you enable this section and check the appropriate roles

works for me :-)

Hi!

Also just noticed this and came in from Google, another workaround is using the Administration theme module which provides the permission "Access admin theme".

http://drupal.org/project/admin_theme

BTW, this is not a problem on D7.

Check this patch.

I don't think that adding a permission to D6 is going to fly...

But setting to 'nr' for other opinions.

@joachim

This is drupal 7 way.
http://drupal.org/node/137198#comment-3788108
We can think about this like a backport.

Ah sorry my mistake. In that case, yes, makes perfect sense.

Seems there won't be a D6-fix. Anyway, it seems it could be fixed without hacking core by a custom module implementing hook_init() which should be invoked after system_init(). In my case for example I don't want to show the admin-theme for anonymous users, so I set it back to custom theme:

/**
 * Implements hook_init().
 */
function custom_module_init() {
  global $custom_theme, $user;

  // Do not use administrative theme for  anonymous user.
  if (!$user->uid && $custom_theme && $custom_theme == variable_get('admin_theme', '0')) {
    $custom_theme = variable_get('theme_default', 'garland');
  }
}