User should be redirected once logged in [SOLUTION-COREERROR]

as opposed to a patch..you could try this....

// get referrer from _SERVER array 
$ref = $_SERVER["HTTP_REFERER"]; 

and insert this into your form action line:

form action="user/login?destination=$ref" method="post"

The php script at the top catches the reffering url and assigns to to the $ref variable...
I haven't tested the above, so it's only a suggestion...might be easier to implement that in your custom 403 page rather than wait for a patch.

Dub

Thanks for the patch nysus.

I don't mind removing the $maycache, but it may be a performance hit for some large sites.

I think the patch as it exists, is overly overcomplicated. Too much code in there.

The reason you were getting different users getting each other's path is that it is saved in the database.

I was thinking of something along the lines of what Dub said. Check if the referrer is set, and then issue a drupal_goto().

Try to replace the customerror_page function with the version below, merged to the original module (not the nysus modified one).

I did not test it though.

function customerror_page() {

  $error = arg(1);

  switch($error) {
    case 404:
      drupal_set_title(variable_get('customerror_'. $error .'_title',
        _customerror_fetch_error($error)));
      $body = variable_get('customerror_' . $error, _customerror_fetch_error($error));
    case 403:
      //
      $referer = $_SERVER["HTTP_REFERER"];
      if ($referer) {
        drupal_goto($referer);
        }
      break;
    default:
      drupal_set_title(t('undefined error: ') . $error);
      $body = _customerror_fetch_error($error);
      break;
  }
  print theme('page', $body);
}

Just realize that this may cause a redirection loop (403 -> original page -> 403 -> ...).

Oh well. Someone may think of something better.

The session ID is a good unique identifier.

So, we could use the Session ID to identify the original page that we would redirect to.

However, if we use variable_get() this means there will be one entry per session, and on a large site, this can be a) too big, and b) a significant overhead

Unless we delete it from the table upon redirect, which solves a) but worsens b) (more db operations).

Perhaps we can make this a config option. If the site is small, then this is a good option to turn on. If it is a large site, then the site admin should turn this off.

+1

Please do not change the title. It will make it difficult for others to find the issues.

As for a solution, the patches provided seem to work, but they are overly complex.

I am not going to apply them as is, unless a simpler and cleaner patch arise.

Has there been any progress on this? It may seem like a minor issue, but it is a real show-stopper for a site that I am trying to port to drupal.

Users are not permitted to see any content without being logged in, so the custom 403 page serves very well as a "welcome, please log in" screen... but when they log in they still see the "please log in" message. They're going to find that very confusing.

As far as the solutions mentioned, they are too complex and not simple and clean.

I am waiting for someone to put a better patch, since I am not working actively on this at the moment.

When this patch is in core, it could be the basis of a better solution.

Maybe the previous patch to CustomError can be reworked in the future to use this.

Redirection is now in core. Check it here http://drupal.org/node/26467

Anyone cares for a patch based on that?

I'm investigating this issue

as far as I can say now it is _no_ error of customerror its an error of the user-login-block and a little bit of menu_set_active_item()
(the form-destination is set to the URL of the error-page)

maybe youll get a solution today.

but this will affect the core.

i dont want to change the Project/component by now.
but if I have a solution

cu tobias

I found a solution
1. As I mentioned this is no error of customerror!
2. this is a bug and no new feature witch should come (because it is done the right way if you are not using any other errorpage

the patch adds the line
$_REQUEST['destination'] = urldecode(substr(drupal_get_destination(),12));
to drupal_access_denied()
--> the $_REQUEST['destination'] is now set before user_block() asks for destionation

Ciao Tobias

The patch is garbled (DOS editor?)

Here is the same patch in a proper format so others can review it.

What I do not like is the 12 in the substr. This kind of hard coded numbers has to be at least documented so it can be changed in the future if need be.

i dont like it too
but this was the fastest way to do it :D
here comes a new patch

but this changes drupal_get_destination() a little bit

cu tobias

erlinofchaos has a more current patch on this in the queue