As of now, a person could create a new node with a URL alias that overrides a menu_router entry. For example, one could create an article with the alias "node/add/page". Then when attempting to create a page, they would be redirected to the offending article.
It occurs to me that if a path is in the menu_router table, it should not be eligible as a URL alias.
Comment | File | Size | Author |
---|---|---|---|
#5 | path_validate_menu_router-1561372-5.patch | 741 bytes | Kevin Hankens |
#1 | path_validate_menu_router-1561372-1.patch | 972 bytes | Kevin Hankens |
Comments
Comment #1
Kevin Hankens CreditAttribution: Kevin Hankens commentedAdding patch.
Comment #2
gregglesPatch makes sense to me, let's see what testbot thinks.
Comment #4
gregglesThe failures are in PathAliasTestCase
Attempt to moved alias was rejected.
"The alias is already in use." found
I didn't dig in, but it seems like test is relying on this bug...?
Comment #5
Kevin Hankens CreditAttribution: Kevin Hankens commentedOh, that was my bad. I changed the dsm to have a more friendly message. The assertion was looking for the old error message.
This patch uses the old messages instead.
Comment #6
Kevin Hankens CreditAttribution: Kevin Hankens commentedComment #8
Kevin Hankens CreditAttribution: Kevin Hankens commented#5: path_validate_menu_router-1561372-5.patch queued for re-testing.
Comment #10
Kevin Hankens CreditAttribution: Kevin Hankens commentedI don't understand these failures, the only thing that changed from the first patch was the argument to form_error. Although, this did fix the path tests :) Any thoughts?
Comment #11
Kevin Hankens CreditAttribution: Kevin Hankens commentedIt appears that these five failures also happen locally on a fresh install /without/ the patch above.
Comment #12
moshe weitzman CreditAttribution: moshe weitzman commentedI wonder if people use this feature to "take over" paths generated by modules.
Comment #13
chx CreditAttribution: chx commentedThanks for trying to fix this but the approach taken is not acceptable. Going around an API to work with a database table directly is, in general, wrong. Here, I would run
menu_get_item()
first and then take a good look at the resulting$item['path']
. This would deal with the problem of having a pathfoo
and an aliasfoo/bar
. Something rather similar to http://api.drupal.org/api/drupal/includes%21path.inc/function/drupal_val... except you do not need to deal with dynamic path but need to be able to look at the$item
itself.Comment #14
gregglesHmmm, yeah, moshe is right. We shouldn't prevent that in path.module.
Comment #15
cweagansThere's already a good way to take over paths generated by modules. I don't think it makes any sense to allow somebody to create a node over the top of an existing menu_router path - at least, not without warning them.
Maybe this is a silly example, but what if somebody created a webform over the top of /user/login and started collecting user credentials from the users of the site? That would be less than ideal.
Comment #16
nmc CreditAttribution: nmc commentedI'd like to see this "fixed" in core as well.
Along the same lines as @chx, why not do as Pathauto does in its _pathauto_path_is_callback?
Here's the revised version:
The second part of the code above seems ideal to me as well. That way we can avoid these situations: http://groups.drupal.org/node/20604
Comment #29
smustgrave CreditAttribution: smustgrave at Mobomo commentedJust verified on 11.x that this can still happen.
Comment #30
smustgrave CreditAttribution: smustgrave at Mobomo commentedActually seems like a duplicate