Hi!

This is what happens:

1. As a not logged in user I go to http://www.mysite.com/admin
The 403 page is displayed with the admin theme activated and the user login displayed in the left sidebar.

2. I try to log in. Although I am positive the login details are correct, instead of being logged in, I am now sent to the 403 page again but this time at the address http://www.mysite.com/customerror/403?destination=admin

Questions:
1. Why does logging in not work? Seems like a bug to me.
2. Actually I'd prefer it if the 403 page was displayed with the main theme, as is the 404 page. (See also #278575: Admin theme is used on error pages below /admin.)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kodo’s picture

Hi, you can try return back this changes http://drupalcode.org/viewvc/drupal/contributions/modules/customerror/cu...
I had the same problem. It helped me.

PWG’s picture

Thanks, kodo. I'll try it. Sorry for replying so late.

hermes_costell’s picture

The solution above doesn't solve the problem as of 11/4/2010.

Correct solution:
On the admin/settings/customerror page anywhere inside the "Description for 403: " block place this code:
menu_set_active_item($_REQUEST['destination']);
And check the "Allow PHP code to be executed for 403" box.

carn1x’s picture

Version: 6.x-1.1 » 7.x-1.x-dev

This issue is still relevant for the latest 7.x-1.x-dev

EDIT: Actually maybe this is slightly different. I find that the visual behavior indicates that logging in isn't possible, however I am actually successfully logged in. It's not that login doesn't work, but simply that the login form action is set to "/customerror/403?destination=path/that/generated/403".

I've fixed this particular issue on my site by modifying any form action to remove the customerror/403:

function mymodule_form_alter(&$form, &$form_state, $form_id) {
  if (strpos($form['#action'], 'customerror/403?destination=')) {
    $form['#action'] = urldecode(preg_replace('/customerror\/403\?destination=(.*)/', '$1', $form['#action']));
  }
}

So instead of the form posting to "/customerror/403?destination=path/that/generated/403", instead the user is sent to: "/path/that/generated/403"

rconstantine’s picture

I ended up changing the following function thus:

/**
 * Implements hook_user_login().
 */
function customerror_user_login(&$edit, $account) {
  // Check if we have a destination saved in the session
  if (!empty($_SESSION['destination'])) {
    // If there is one, then set the REQUEST destination to it
    if (strpos($_SESSION['destination'], 'customerror/403?destination=') !== FALSE) {
      $_SESSION['destination'] = urldecode(preg_replace('/customerror\/403\?destination=(.*)/', '$1', $_SESSION['destination']));
    }
    $_GET['destination'] = $_SESSION['destination'];
    // And clear the one in the session
    unset($_SESSION['destination']);
    // user.module then does a drupal_goto() for us after we return from here
  }
}
free6512’s picture

Thank you rconstantine, that solved my issue!

rconstantine’s picture

Status: Active » Needs review

In that case, I'm changing the status.

sunshine32818’s picture

This worked for me, but only if I logged in correctly. After a login failure occurs, a successful login on the second attempt does not redirect the user to the homepage instead it logs me in but shows the Access Denied message still.

gisle’s picture

Please find attached a patch that fixes this issue. It should be applied to the current head of the 7.x-1.x branch (with SHA-1 starting with 392d341ec...).

When requesting a 403 page, the user is redirerected to the page requested after successfully logging in. This version also works if the the user mistypes username or password before getting it right.

Please review.

mrfelton’s picture

Patch in #9 works for me. Thanks.

gisle’s picture

Status: Needs review » Fixed

Patch in #9 committed on May 2, 2013 19:13 (commit 9ad93b4 on 7.x-1.x branch).

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

gisle’s picture

Version: 7.x-1.x-dev » 6.x-1.2
Assigned: Unassigned » gisle
Status: Closed (fixed) » Needs work

This fix needs to be backported to 6.x-1.x-dev branch.

gisle’s picture

  • Commit 9ad93b4 on 7.x-1.x, 8.x-1.x by gisle:
    Issue #825860 by gisle: Logging in on 403 page does not work.
    
gisle’s picture

Assigned: gisle » Unassigned
Issue summary: View changes

I am not going to work on issues affecting D6.

gisle’s picture

Status: Needs work » Closed (outdated)

The Drupal 6 branch is no longer supported.