Login results in "Access denied"

Looks like "user/login shouldn't be accessible for logged in users" might have caused this problem. In particular, this segment:

@@ -900,6 +900,7 @@ function user_login($msg = '') {
     '#attributes' => array('tabindex' => '2'),
   );
   $form['submit'] = array('#type' => 'submit', '#value' => t('Log in'), '#weight' => 2, '#attributes' => array('tabindex' => '3'));
+  $form['#action'] = url('user');
   return $form;
 }

It doesn't appear that the uid can be included in that action since the user hasn't logged in yet.

Sorry, "user/login shouldn't be accessible for logged in users" -> http://drupal.org/node/69985

This is the simple fix for it. Note that the code alreasy present in the beginning of user_login to deal with the case when called after login. Cases tested: logging in from block when viewing a node (landed on the node), logging in from 'user' (landed on user/1), trying to access user/login when logged in (landed on user/1 again).

the whole point of making user/login inaccessible is that you could add that path to a menu and it would only show up for anon users. this patch reverted that. perhaps a better fix is to point the login form at some path other than user/login.

So, you guys want a user/login which is accessible for anons only so you can add it to the menu?

The access attribute for the menu item of 'user' is never consulted because there is a default task. On the other hand, the callback attribute of user/login is totally unnecessary, because it will happily fall back to the one given at user and if you do not give one for user then you won't get a user login callback at 'user' when anonymous. So, if you want, you can use this patch as well. It will drive people nuts, but noone understands menu system anyways, so it does not matter.

I wasked about my last sentence: people here are the poor developers who need to understand user_menu and need to compile a [callback, callback arguments, access] package from two definitons... or this is my current understanding. Let' see whether the second patch works or not...

Doing a redirect while building the menu? This looks like an ugly solution to me. Can't we chose not to add the menu item when $user->uid is set? I'm trying to understand why we add the menu item to begin with.

I have been asked that the path user should provide the login form when anonymous and the view of current logged in user otherwise. I have been asked to make it so that if someone adds user/login to his menu then it disappear when logged in. If there is any other way to satisfy all these requirements, it escapes me.

Note that I redirect during hook_menu !$may_cache because this is the earliest stage when such a redirect is feasible.

Also note that the big menu rewrite will clean up this "default task links to parent" nightmare but at this stage attemtping to change the behaviour of the menu system is not the best solution.

@dries - the reason we need a 'user/' menu item is that we want to write links to 'view your user profile' from within a node or comment but not require php permissions to do so. in other words, a link which does not require knowing the current uid. already, it is impossible write a link to 'edit you user profile' without php access and thats a support problem on my sites and on drupal.org

This patch works, you can have a login link in your menu if you point that to user (user/login does not work because of http://drupal.org/node/72674 ) . This patch depends on http://drupal.org/node/88707 .

Note that this also does a redirect while building the menu just an 'inner' redirect. I still can't find any solution not employing redirection.

chx asked me to have a look at this issue.

I agree with chx and Moshe that this is a problem that should be addressed.

I also agree with Dries that this solution looks a little ugly.

But I can't immediately see a better way.

So, we either commit #6 or commit http://drupal.org/node/88707 (which is needed anyways) plus #14.

I tried #14-
patching file modules/user/user.module
Hunk #1 FAILED at 690.
1 out of 2 hunks FAILED -- saving rejects to file modules/user/user.module.rej

I think the way to test this is to log in and go to '/user' and '/user/login' and see if there is any problem, but I couldn't find any with unpatched code.

Rerolled, added comments.

What do you mean with 'without writing PHP code'? I think the code comment is quite fuzzy.

Per Drumm's request, this patch serves lets you create two menu items (primary links):

1. This points to the login form, but should not appear when logged in.
2. This points to the logged in user's profile.

If you say this is a feature request, I do not agree. This was possible but was broken by the bugfix committed earlier.

Committed to CVS HEAD. Thanks.

Yup. (how come these lines were not removed? ? ? anyways, this ends our long and ugly journey, I hope)

Committed to CVS HEAD. Thanks.