Cannot create path alias for 'user/login'

path_admin_form_validate() do check if the user adding the path has access to it:

  $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.

And #286683: add alias /register with path -> "invalid or no access" error was a duplicate.

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:

you're already logged in as %username%, if you wish to login as another user enter your login below or click here to logout.

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

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.

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.

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.

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.

This is a duplicate of: #190867: Remove access check for anonymous users when creating aliases