When updating from 4.6.5 to 4.6.6 users can't login. When reverting user.module to 4.6.5 it works again.

What version of PHP are you using? The security fix for Drupal 4.6.6 requires PHP version 4.3.2 (which is below the minimum of 4.3.3 required for that release, so you should be okay).

--
If you have a problem, please search before posting a question.

and I am not having this problem.

What's the difference between your user module and the 4.6.6 one? Did you modify it?

The patch to user.module is the addition of 4 lines related to generating a session id.

I've just upgraded my drupal from 4.6.4 to 4.6.6 and have the same problem.When a registered user attempt to log in , it seems on admin panel as "logged in" but user isn't. Any ideas?

Any help if you empty/truncate the sessions and cache tables?

Laura
_____ ____ ___ __ _ _
pingVision, LLC • BlogHer • rare pattern • scattered sunshine

My upgrade process:

1. Read the patches; see that they affect the the following files:

• common.inc
• menu.inc
• book.module
• user.module
• xtemplate.engine

2. Upload the new files listed in step 1.

My environment is:

MySQL 4.1.14
PHP 4.4.1
Apache 1.3.34

If you are having the problem mentioned in this thread, please post back with your operating environment, as that will help to troubleshoot the issue --

Cheers,

Bill

-------
http://www.funnymonkey.com
Tools for Teachers

I patched three sites, no problems.

--R.J.
http://www.electric-escape.net/

I think the problem is that the session id is not being explicitly set as shown in the documetation.

      $old_session_id = session_id();
     session_regenerate_id();
      db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);

      session_start();
      $old_session_id = session_id();
     session_regenerate_id();
     $new_session_id = session_id();

      db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", $new_session_id, $old_session_id);

This might also be because the session cookie does not change in 4.3.2 but it does change in 4.3.3.

I might be helpful to know if you are running windows also.

* knock wood *

6/6 sites so far, without a hitch. (Although I have to keep rewriting the file paths as "cvs" does not figure in the installs I have. I'm sure I'm missing some obvious *nix option to avoid all that typing.)

Edited to add my "duh" moment: proper syntax:

patch -p0 < 4.6.5.patch

I will now take my learning curve back off-line.

PHP 4.4.1. MySQL 4.1.14.

Laura
_____ ____ ___ __ _ _
pingVision, LLC • BlogHer • rare pattern • scattered sunshine

I tried to update my two drupal sites running 4.6.5 by downloading the tarball and then just replacing the affected files,

common.inc
menu.inc
book.module
user.module
xtemplate.engine

After that was done I tried to log in to the page but it didnt work, the site went blank and the url turned www.example.com/en/user/login?destination=user
(yes, i'm using i18n)

I cleared the sessions and cache tables and local cache of browser and tried to open the homepage but this time nothing happened at all (page went blank). I'm using phptemplate instead of xtemplate so I also downloaded the engine file from CVS but without any improvements.

So I uploaded the old menu.inc file and now I can see the site again, but not log in (same error as before).

Any tips what it can be?

Edit:
One of the sites was successfully updated! But it is not running i18n module. Both are on same server environment though.

---
Running Apache, PHP 4.4.1, MySQL 4.0.24

The user.module patch prevents login on several sites I have. I will investigate more, but for now I am using the unpatched version.

FYI... Experiencing the same problem with the 4.5.8 release. Backing off to the previous 4.5.7 user.module works fine.

I upgraded my php version after reading the previous posts. It was previously at 4.3.2. Still getting the same results.

Specs:
RHEL 3 ES Update 7
Apache 2.0.46
PHP 4.4.2
MySQL 4.1.16

Same problem here too... php version 4.3.2.
Reverted to old user.module and now i am able to login.
Is there a security problem if i am using the old user.module?

Apache version 1.3.34 (Unix)
PHP version 4.3.11
MySQL version 4.1.13-standard-log

The edit shown above re session_id did not help.

I have copied in the 4.6.5 user.module as a temporary fix.

I'm having the same problem. Has anyone raised an issue/bug for this?

It's a showstopping bug.

Dub

Hi.

For what I can say, i hit this bug when use php 4.3.2 (on some hoster).
The solution is posted before here:
http://drupal.org/node/53838#comment-101856

You have to:
* verify which php version is
* apply the suggested fix

Hope this help.

PHP 4.4.1
Linux 2.6.9-22.0.1.ELsmp
MySQL 4.1.14
Apache 1.3.34

Followed the documentation to perform the patch. Can't log in and neither can anyone else trying to use the site. Flushed the tables. Nothing. Tried putting back the affected .module pieces (4.6.5 modules). Still doesn't work.

I suppose if I were a programmer I would know what to do with PHP -- but I don't. I hope a fix appears soon because I've decided to go back to 4.6.5 and take my chances.

I have 2 clean Drupal 4.6.6 versions: one locally with Windows + IIS + PHP 4.4.0 and then one on the hosting wich has Unix + Apache...

Online I was able to create account and log in wihout any patch nor anything.

Locally, I was not able to login, nor to fix it with any of the things/solutions I have read on the forums.

Any thoughts?

Clauz
---------------------------------
http://www.clauz.com.ar
...I am going through A Momentary Lapse of Reason...

We were definitely experiencing the same problem. Since we're locked into PHP 4.3.2, the latest user.module 4.6.6 code with the session_id() caused problems. Our workaround was to create a custom block that only shows up on:

http://<yoursite>/user
http://<yoursite>/user/login

pages. Please note that this will not work if you use the user_block (mini-login). I would recommend you disable that and create a custom block that takes users to the generic login screen. This also requires that javascript be active in the users' browser.

<script language="JavaScript" type="text/javascript">
   function DestroyCookie() {
      document.cookie = "PHPSESSID=;path=/;expires=Thu, 01-Jan-1970 00:00:01 GMT";
     // alert("Session ID destroyed. You may now login.");
   }
DestroyCookie();
</script> 
<noscript>To login, Javascript needs to be enabled.</noscript> Login with your username and password.

I implemented this because I didn't feel like patching the core knowing that a fix will likely be out sometime soon.

The other option is to simply comment out the following three lines in the user.module:

(somewhere around lines 816-818)

      $old_session_id = session_id();
      session_regenerate_id();
      db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);

but then you're bypassing the security patch update.
--
Michael Jelks
http://www.planetizen.com
http://www.zaftig.net

http://drupal.org/node/60584