user/register should show custom message instead of 403 for logged-in users

Agree, I have the same problem with 4.6.2.

here comes a patch for this

i needed relatively long to find out why this happens.

the behavour was theoretically implemented but hook_menu() denied it...

I'd rather opt for Drupal to display a message along the lines of 'You can't register an account because you're already logged in.', instead of an equally confusing redirect. Secondly, I'd like to see consistency: If you're logged in now, and try to request a new password, Drupal will give you a 403 as well.

Renaming and moving to 6.x queue. This is still relevant, and I for one think it's a valid issue.

Still to be fixed.

This behaviour is still present in Drupal 7.x-dev (2009-Mar-14) - updated status to reflect this.

OK, I've thrown a patch together for 7.x-dev (2009-Mar-14).

Currently, the following happens when user/login, /password, and /register are called:

• When the menu module checks for access it calls the user_is_anonymous() function. (/register calls this function indirectly, via user_register_access())
• user_is_anonymous() returns true if the two conditions are met:
  • No user id is currently set (i.e. no user is logged in)
  • $GLOBALS['menu_admin']) is empty (i.e. a menu administrator is not running an access check - Drupal API reference)

This patch does the following:

• If the two above criteria are not met (i.e. noone is logged in, and a menu administrator is not responsible for the current check), then it sets a drupal message to display on the 403 error page.
• Drupal will then display a 403 Access Denied page, as access is denied, so this will not confuse matters (see comment #3)
• The message displayed states that the page cannot be accessed because the user is currently logged in, including a link to the current user's page and the user's name, along with a link to log out, which automatically redirects to the current page. This would then be accessible, as the user will be logged out.

Ooo, now why would that happen? I shall go investigate!

As a side, I forgot to call t() for the error message - here is my patch with t() called.

I guess it'll probably fail, if the last one did though, I'll see if I can figure why...

Switching to code needs review, see if it'll like this patch...

Think I've sorted out the patch not applying issue - I was creating the patch without using CVS (instructions at http://drupal.org/patch/create, Quick start example (diff) - I think it put my system's file path in the .patch file, instead of just the relative path. Is this a separate issue?)

OK, let's try this again!

There are several code-style issues that need to be fixed, notably capitalization of booleans, spacing around operators, inline comments not capitalized and not on a separate line.

For the rest:

Could we please get an optional parameter to suppress the message?

user_is_anonymous() isn't just an access callback; it's a boolean function that could be used by any module to show different content to guests, and these calls shouldn't result in an error message.

Unless this function should not be called by any module other than the menu system, in which case it should be documented as such - for example by telling developers to use !user_is_logged_in() instead.

How about something based on this approach?: http://drupal.org/node/118498#comment-1891590

Is there any patch or mini-module to correct this in 6.x?

subscribing from #600472: Confused users: Already logged in users get 403 on user/login or user/register

adding my tags

Adding Usability tag

a.bond

To address the issue in Drupal 6, I borrowed some code from what others had posted in a related thread and made a module called Already In.

What we have in Drupal 7 right now looks a bit broken (not impacting functionality, but not the right way to do it either):

function user_register_access() {
  return user_is_anonymous() && variable_get('user_register', 1);
}

// hook_menu()
  $items['user/register'] = array(
    'title' => 'Create new account',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('user_register_form'),
    'access callback' => 'user_register_access',
    'type' => MENU_LOCAL_TASK,
  );
  $items['admin/people/create'] = array(
    'title' => 'Add user',
    'page arguments' => array('create'),
    'access arguments' => array('administer users'),
    'type' => MENU_LOCAL_ACTION,
  );


// user_register_form() (called for both of the above menu items).
  global $user;
  $admin = user_access('administer users');
  // If we aren't admin but already logged on, go to the user page instead.
  if (!$admin && $user->uid) {
    drupal_goto('user/' . $user->uid);
  }

user/register is accessible only when the user is not logged in. admin/people/create is only available for user-admins. user_register_form() is only called when either of these is true, and the (!$admin && $user->uid) expression should therefore never be true. Redundant check is redundant?

subscribing, thx.

This is covered by #363580: OpenID login fails when in maintenance mode.

this is still a problem for core in D6.20 - going to user/login returns access denied.

I've been going round in circles trying to find where to post this issue.
so have posted a new issue
http://drupal.org/node/1112824

#8: useraccesserror.patch queued for re-testing.

I believe this was closed as a duplicate and #363580: OpenID login fails when in maintenance mode is the issue where it will be resolved. If there is a reason this is not a duplicate, please indicate so here.