Curious Drupal/PHP session problem causing 'Access Denied'

Hi there everybody,

I post this here in the hopes of someone more knowledgeable explaining this strange occurrence to me, or that it might help someone else with a similar problem. I searched through many, many threads before posting here and found lots of similar issues, none of whose solutions worked for me. The problem is that I am getting 'Access Denied' pages from drupal after any of my users try to login.

I originally built the site on a test server where everything went fine and was able to serve the site as a demo from an IP address using both Apache and IIS 5.0 on windows XP with no problems. All users can login fine, so I know the drupal setup is ok.

I moved it onto a production server by doing a database dump and copying the drupal directory to the server. This went without any hitches and the site appears fine for anonymous users and the database cloned fine using phpmyadmin. However, now when anyone tries to login, it is as if the login does not take, and drupal returns an 'Access denied' error (not an incorrect password error) on any pages which the authorised user should be able to see. This happens for any authorised users.

Ok, so I thought, it must be something to do with the login state being carried over from the test server. So I cleared the cache and session tables. No luck there. Then I did a clean install of drupal on my production server which went fine up until the point I created the first (admin) user and tried to login at which point I had the same error.

It it clear there was some compatibility issue with the production server, but I couldn't work out what it was. It was running the same versions of Drupal, IIS, PHP and MySQL as the test server, php.ini was identical, the only change was that instead of an IP address it now had a domain name.

I am running on both servers:
- IIS 5 on Windows server 2000,
- Drupal 5.3
- php 5.2.4
- mysql 5.0.45-community-nt

Watching the session tables as I navigate the site narrows the problem. When I first hit the production site as an anonymous user I see a session created for user id 0. This session id matches the one set in the browser (firefox) cookie. So far so good. The problem comes as soon as I click the login button on the user page. What happens is that a second record is created in the sessions table with a new session id for user id 1 (the admin), but this is not updated in the browser cookies. So internally, user 1 has been logged into drupal but is given a new session which the browser cannot access. The first record remains so that the users cookie is still registered as an anonymous user. What ought to be happening is that the user id for the existing session is updated to reflect the users new status, or that the browser cookie be updated with the new session id.

I looked around the forum and found many similar issues and solutions, mostly for earlier versions of drupal which claim to have already been patched. Initially I thought it was something to do with the domain change and that the $cookie_domain value was not set correctly. After much hacking of session.inc and fiddling with the session table manually, I discovered that the cookies were being read fine. For instance, if i manually modified the user id for the session matching the cookie to '1' I could get admin access. So the system was obviously reading the value from the cookie and there seemed to be no problem with the sess_read() function.

It seems that somewhere in the sess_write() function called after the login button is pressed, the user is being assigned a new session id rather than using the existing one. After some tracing, i discovered the problem is on these lines in session.inc:

function sess_write($key, $value) {
  global $user;

 ...

  $result = db_query("SELECT sid FROM {sessions} WHERE sid = '%s'", $key);

  if (!db_num_rows($result)) {
    if ($user->uid || $value || count($_COOKIE)) {
      db_query("INSERT INTO {sessions} (sid, uid, cache, hostname, session, timestamp) VALUES ('%s', %d, %d, '%s', '%s', %d)", $key, $user->uid, isset($user->cache) ? $user->cache : '', $_SERVER["REMOTE_ADDR"], $value, time());
    }
  }
  else {
    db_query("UPDATE {sessions} SET uid = %d, cache = %d, hostname = '%s', session = '%s', timestamp = %d WHERE sid = '%s'", $user->uid, isset($user->cache) ? $user->cache : '', $_SERVER["REMOTE_ADDR"], $value, time(), $key);

   ...
  }

This query was returning zero matches, meaning that an INSERT was being done rather than the expected UPDATE. Tracing this back further, it appears the wrong value of $key is being sent to this function.

After much gnashing of teeth for the last 3 days I came up with this solution. If I manually replace $key at the top of the function with:

  $key = 'key_from_my_cookie';

or more generally:

  $key = $_COOKIE[session_name()];

The login works for each user. I tried to trace back where the sess_write() function is called from but can only find a reference to it in bootstrap.inc where it is set by the PHP session_set_save_handler() function. Unfortunately, not knowing more about drupal or the inner workings of PHP I can't trace back where the $key value comes from.

Can anyone tell me why this works, if it is a security problem and if there is a better way to solve this? I would rather not hack drupal core if i can help it :-)

Thanks for reading my (rather long - sorry) post and hope someone can help.