Drupal 4.6.2 Doesn't allow login (IIS 5.1, PHP 5.0.4)

I fail to see why this is needed and where is the patch? I searched for _VARS in Drupal HEAD, there is not a single instance of it, and frankly, I doubt we have had any in a long time.

no patch

Won't change settings.php for such a special case.

I've made a note in the Drupal Handbook under IIS installations, though.

Thanks for the information!

Djun

I can't verify this. On an installation with php5.0.4 it works without issue on IIS6

I'm having the same issue with CVS/Druapl 4.7b6 on an IIS box at the moment. I'm still trying to figure out if it's a config issue or a very, very subtle drupal issue. The register_long_arrays = On fix does NOT help in my situation, though. Further investigation will follow.

I do not think that it's an bug, at least not in Drupal.
I am currently doing some work on IIS and at the beginning of the project I sent a few weeks battling with Windows/IIS and the WAMp components. I had a similar problem in which I was not able to login in one version of Drupal, and 4.65 was running into SQL failures during installation in phpmyadmin.

At that time, I was running the latest and greated of PHP and mySQL. I solved the problem by downgrading PHP to 4.42, mySQL to 4.1.16 and Apache will work with 2.x or 1.3.x (if you use 1.3.x of apache, make sure that you use OLD_PASSWORDS in the database, otherwise you will run into another problem http://www.cmsproducer.com/click/117/3).

In addition to not being able to login properly, I also had trouble getting Apache to call PHP as a module (If you use it as CGI, mod_rewrite will not work well - clean URLs, and you might not be able to see mySQL from PHP). If you use IIS as your server, it should be similar although you will not be able to do clean URLs. Here is a document that I wrote about my ordeal with mySQL 5.x in Windows.

http://www.cmsproducer.com/click/5/3

NB: I tried to solve the issue using both Apache and IIS on Windows Server 2003 Web edition

At that time, I was running the latest and greated of PHP and mySQL. I solved the problem by downgrading PHP to 4.42, mySQL to 4.1.16 and Apache will work with 2.x or 1.3.x (if you use 1.3.x of apache, make sure that you use OLD_PASSWORDS in the database, otherwise you will run into another problem http://www.cmsproducer.com/click/117/3).

Rather than using OLD_PASSWORDS, you could simply tell PHP to use the original MySQL client library with f.e. something like --with-mysql=/usr, instead of the one that provides PHP itself (used when MySQL is compiled with --with-mysql).

@Eaton: Not sure if this applies, but I've read there might be problems is register_globals is on. Another thing to try would be to call session_write_close() just before header('Location: ') (in drupal_goto). Also, if you have 404 errors redirected to Drupal, you might want to check you don't have 404 errors generated by the page itself; these may generate additional requests that can override session data (this can happen too if the browser requests a favicon and you don't have one). ...just some ideas...

Having previously mis-understood the issue, I got to research it when a customer ran into the same problem and I had to fix it.

After a good research session and looking for a solution on Drupal.org, I was able to find a solution that works for me in consistently in Drupal 4.66 and 4.7. The problem is obviously caused by an anonymous cookie string being used in the logged in session. To solve the problem, in the user.module file in the modules directory, edit the lines 947 - 954 in the user.module of Drupal version 4.7 contains the function that authenticates users and creates a $user state variable.

function user_authenticate($name, $pass) { global $user;

// Try to log in the user locally. Don't set $user unless successful.
if ($account = user_load(array('name' => $name, 'pass' => $pass, 'status' => 1))) {
session_regenerate_id(); //added procedure to recreate session
$user = $account;
};

Also, you will beed to comment out the three lines preceeding this function:
-----
$old_session_id = session_id();
session_regenerate_id();
db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);
-----

By regenerating the session ID, you will drop the anonymous ID and pick a new one for the logged in session - You can see the detailed solution to this common bug by checking this Drupal resource.