hook_menu_alter() sounds right. You could also use some sort of detection mechanism in hook_menu_alter() to report that the path was overridden. I am a firm believer that this sort of thing should be handled by negotiation between module maintainers and documentation, rather than by beginning a programmatic war for possession of namespaces. On Mon, Nov 22, 2010 at 6:15 PM, nan wich <nan_wich@bellsouth.net> wrote:

My first thought would be a hook_menu_alter to set it back to the right path. Granted most of the time it will be unnecessary overhead, but if the path is critical, it should work.

Nancy

Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

________________________________ From: David Metzler <metzler.dl@gmail.com> To: development@drupal.org Sent: Mon, November 22, 2010 8:24:25 PM Subject: [development] Protecting URLS From Path

I maintain an SSO module that has an alternate login path (cas instead of user/login).  I recently got a post asking if there was a way for me to programmatically protect it from being overridden.

A user had created a page describing the single sign on process and given it the same URL as my menu_hook was registered, thus overriding the behavior provided by my module.

So I thought I'd ask.  Anyone know of a way for me to ensure that other menu paths (specifically aliases) cannot override the one provided by my module?

Dave

A user had created a page describing the single sign on process and given it the same URL as my menu_hook was registered, thus overriding the behavior provided by my module.

So I thought I'd ask.  Anyone know of a way for me to ensure that other menu paths (specifically aliases) cannot override the one provided by my module?

The Path/URL Alias API is still very poor, especially in D6. For D7, we heavily improved it, but I doubt that there is a clean way for your module to invalidate resp. prevent a path alias from being stored. The possibility of being able to alias real/internal paths is a powerful feature. But of course, users who do not know about Drupal's system internals can unintentionally break actual module functionality by entering an alias that is identical to a system path. An easy way around this is to use modules like Pathauto and to configure/tweak them so that all aliases follow a "secure" pattern, without allowing users to override the alias to be "insecure". I just did a quick search but couldn't find a module that tries to implement URL alias validation. I'd say that such a validation would be really useful - and should even considered to be moved into core's Path module for D8. sun