Not logged out when logging out

I to see this problemt too, In IE6. Firefox logs me out even when pressing Cancel after logging out.

Reading through the comments on php.net this seems to be a known problem, but with solutions. One idea could bee to see how phpmyadmin solves this.

Whats the status on this? Is it confirmed?

I found some thing wrong with the securesite_user function. At first I thought I solved this problem but in the end it did not.

The unset function is being used incorrectly. You cant unset a global var from with in a function even if it is being passed by reference it only destroys the local version of the var.
http://www.php.net/unset

And I think you right, the function _securitesite_auth(); is being called in the wrong place.

I think this would be better, it destroys the user session, but I don’t think the database sessions table is being updated. If you logout a record of your session is still in the database and that could be were our problem lies.

function securesite_user($op, &$edit, $user) {  
  if ($op == 'logout') {
    unset($GLOBALS['user']);
     module_invoke_all('exit', request_uri());
    _securitesite_auth();
    exit;
  }
}

I don't see why the call to hook_exit() is needed, so I removed it.

I ran my site for a short while with out the exit hook and what I found is that the pages where not being logged for Anonymous uses when at the login page. After looking around I found that the statistics module uses the exit hook to log info. So I put it back and added in another place.

This way I can track the amount of people that stumble onto the site that don't login.

The securesite_user() function contains a typo.

 _securitesite_auth();

Note the spelling. Search for that and change it to:

 _securitesite_auth();

I'm attaching a patch for the 4.7 version of the module, since it came up recently for me.

Here's a patch for the 4.6 version of the module. Important: use this patch if you have the 4.6 version of the module installed, the above one for 4.7.

yeah. i bet the typo is the problem there.

when logging out, the HTTP AUTH dialog _MUST_ be shown. Otherwise the browser doesn't wipe out your auth properly

it sucks

I tried changing the typo and it did make things worse. I started getting locked out and got other php errors. Now everything is so messed up, I can't even use the module at all without my site going nuts. I tried reinstalling and but still got locked out.

I made a copy & paste error in my comment above. My bad. So it should be changing

_securitesite_auth();

to

_securesite_auth();

I submit that the patches I made (see the .txt files I attached above) are still valid and are ready to be reviewed and potentially committed.

Committed to DRUPAL-4-7 and HEAD.

Fixed in DRUPAL-4-6.

I don't think the current solution is ideal and a user can still get into a site without logging in again just by going to the home page or any other page besides the logout page.

I have had a good look into this problem. What I have found is their is no really way to prevent this from happening. You cant reset the PHP_AUTH variables unless the person clicks ok on the auth dialog. Just by presenting the user with the auth dialog does not wipe out the AUTH variables.

I found the following in the PHP handbook. "
Testing with Lynx has shown that Lynx does not clear the authentication credentials with a 401 server response, so pressing back and then forward again will open the resource as long as the credential requirements haven't changed."

From my tests this is also the case with IE and Opera. I have not tested this in Firefox yet.

I also googled the problem, and found some complex workarounds that I struggled to implement into the module using session variables, I also found them unreliable. The best solution that I have found and I also seen used on our ADSL router's admin console, is that you force the browser to close. We just need to find a way that degrades gracefully if JS is disabled. If the browser is closed and reopened the AUTH variables are empty or not present until the user tries to login again.

With tabbed browser like firefox and Opera you just need to close the tab. In opera 8.X their is bug that forces you to need to close the browser rather than just the tab. As far as I know this has been fix in the latest version 9.

I have not tested this if the user has more than one tab open to the same domain. But I don't think this will be a problem as we can close any of the tabs when the use tries to access another page, using a SESSION variable and checking if the PHP_AUTH variables are present.

I will look into this more later this week and see if I can come up with a patch to test.

Sorry Junyor, I retested this after you post, and it does not work for me an IE or Opera. Only Firefox clears the AUTH variables when the auth dialog is presented to the user. For me the solution needs to be browser independent when it comes to security.

When I get time later this week I will try to work up a patch with my idea.

I still (download 4.7) see the behaviour (that's described in the original post) in Opera (win 9.02) and IE (win 6.0). I solved this wayback by adding a random number to all browsers but Firefox.

Here's how the "hack" looked then:


// fix logout on cancel in Opera and IE
$browser_user_agent = strtolower( $_SERVER['HTTP_USER_AGENT'] );
if (strstr($browser_user_agent, "gecko")) { //Firefox
$realm = "gecko-browser";
}
else { //Opera, IE, others?
$realm = mt_rand( 1, 1000000000 );
}
header('WWW-Authenticate: Basic realm="'.$realm.'"');


Close code tags.

Opened new issue 91025.