Cannot create path alias for 'user/login'
flobruit - March 20, 2008 - 21:13
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | path.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | duplicate |
Jump to:
Description
The help page for the path module has 'login' redirecting to 'user/login' as an example of path aliases. However, now that aliases are validated against access permissions, it is impossible to set up this alias unless anonymous users have the permissions to administer URL aliases (because going to user/login as a logged-in user results in an access denied).
When trying to do so on admin/build/path/add, the following error message is displayed:
"The path 'user/login' is either invalid or you do not have access to it."This is not a critical issue, but the least that can be done is remove that misleading example from the help page, and backport that patch to drupal 6.x-dev.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| user_login_alias.patch | 1.72 KB | Ignored | None | None |
#1
path_admin_form_validate()do check if the user adding the path has access to it:<?php$item = menu_get_item($src);
if (!$item || !$item['access']) {
form_set_error('src', t("The path '@link_path' is either invalid or you do not have access to it.", array('@link_path' => $src)));
}
?>
What is the use of the
$item['access']check? There is no security issue involved here, because access control is performed on the basis of the target path, at load time. So... should we simply drop the $item['access'] part?For reference, this was introduced by chx on #154517.
#2
And #286683: add alias /register with path -> "invalid or no access" error was a duplicate.
#3
I think, if you go to /user/login, and are already logged-in, you should still be able to get the login-form, and a message in the trend of:
#4
The check introduced by chx is on the target path, not on the alias.
That is, you cannot create an alias for a target path which either doesn't exist or you don't have access to.
This makes sense IMO.
In any case, it should be possible to create aliases for 'user/login'. They could be useful on multilingual sites.
I think the right way to fix this issue is that proposed by alexanderpas: leave 'user/login' accessible to logged-in users.
"Access Denied" is not the most "user friendly" reply to an already logged-in user who happens to visit 'user/login' ... especially if she is the site-admin :-)
Just my 0.02
#5
There'll be other issues if user/login is accessible to authenticated users - the 'login' menu item depends on an access callback for example. If thing like that can be fixed cleanly, then it probably makes sense to put a message there instead of a 403.
#6
I stand that the access check makes no sense. It's not because you don't have access to a path that you should not be allowed to make an alias to it.
Drop the access check, problem solved.
#7
so, I don't remember whether I was involved in that peice of code, but one could argue that in an extreme case, some users with permission to create aliases should not be able to determine which paths (e.g. nodes) exist. However, since know that the path exists still doesn't even give you the title or any content, I'm tending to agree with the suggestion that the access check be dropped here.
#8
This is a duplicate of: #190867: [BROKE HEAD] Remove access check for anonymous users when creating aliases