When the site handles a 403 response using a custom 403 path (variable site_403) subpathauto_url_inbound_alter() is invoked via drupal_get_normal_path() in the snippet below (common.inc ~ line 2644).

$path = drupal_get_normal_path(variable_get('site_403', ''));
if ($path && $path != $_GET['q']) {
  // Custom 403 handler. Set the active item in case there are tabs to
  // display or other dependencies on the path.
  menu_set_active_item($path);
  $return = menu_execute_active_handler($path, FALSE);
}

This means subpathauto calls menu_get_item() using the custom 403 path. However, during that call $_GET['q'] has not been switched to the custom 403 path so the access checking done in menu_get_item() will result in another 403 (access denied).

$_GET['q'] gets switched over in the menu_set_active_item() but the subsequent call to menu_get_item() (inside menu_execute_active_handler() will use a statically cached router item resulting in that being deemed 403 and spitting out a blank page.

A patch follows.

CommentFileSizeAuthor
#1 2297221_1.patch645 bytessammys
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sammys’s picture

FileSize
645 bytes
loopduplicate’s picture

Hi sammys,

Thanks for the bug report :) One comment

+++ b/subpathauto.module
@@ -20,6 +20,12 @@ function subpathauto_menu() {
+  if (!empty($headers['status']) && $headers['status'] == '403 Forbidden') {

why not use === instead?

Cheers,
Jeff