The security fix which removed the hard-coded 'access' => TRUE for admin-defined menu items has broken external URL support for menus. This was one of the new supported features in 4.7 and should be maintained.

The security fix makes the assumption that every menu item points to a real Drupal path, and that an 'access' attribute will always be found to display it if allowed. However, if a user makes a link to an external URL (or e.g. a relative URL to a real local file), the menu system will not find an access attribute. The menu item will always be flagged as denied (the default), and will not show up in the menu.

Attached is a patch which attempts to fix this. Custom menu items which point to real Drupal paths still act securely: they only work/show up if the user has access to the original menu item/path. However if a custom menu item points to a path for which no access attribute can be found up to the menu root, we assume that it is an external path/file/url, and thus that access control should be granted.

After this patch:

  • Menu item "foo" which points to "admin/access" only shows up if the user has the right permission, because "admin/access" has its own 'access' => user_access('administer access control') .
  • Menu item "foz" which points to "admin/logs" only shows up if the user has the right permission. "admin/logs" has no 'access' attribute, so it is inherited from "admin" which has 'access' => user_access('access administration pages').
  • Menu item "bar" which points to "non/existant" always shows up because 'non/existant' and 'non' are not defined in the menu system (so they have no 'access' attributes).
  • Menu item "baz" which points to "http://www.example.com/" always shows up (same reason... 'http://www.example.com', 'http:/', 'http:' all don't exist).

(before this patch, the last two would never show up).

PS: Though external URL support was not in 4.6.x, it did work (by accident) if clean URLs were turned on. In 4.6.6 it no longer works, which might annoy some people. The same patch can be applied there.

CommentFileSizeAuthor
menu.items.patch1.3 KBSteven
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

m3avrck’s picture

Patch seems to work. Fixes the issue of all of my non-Drupal menu links disappearing (thought there was a bug!).

chrisd’s picture

Application of this patch restored my menus....

Thanks a lot Steven,
Christophe D

chx’s picture

Status: Needs review » Reviewed & tested by the community

yep.

David Stosik’s picture

This patch seems to work.
This bug was very annoying...
It also prevented links to <front> to show up.
Now, my primary links work well, thank you for this quick patch !

Steven’s picture

Status: Reviewed & tested by the community » Fixed

Committed to HEAD and 4.6.

rimshot’s picture

I'd just like to echo the previous comments. Thanks for the quick patch to fix this problem!
WOW. I'm very surprised the SA-2006-001 patch went out the way it did. I tested it on my development server and thank goodness I came across this issue before I applied the patch to my production site. I'm sorry, but things like this make me not too confident to apply to the drupal security patches in the future.

Steven’s picture

You're complaining that a security patch broke a feature that was never supported in 4.6. End of story.

Anonymous’s picture

Status: Fixed » Closed (fixed)