login problems

Sculder, if you assign a bug to yourself, it means you're going to sort it out. Reassigning to noone.

hi,

i tried your link http://shiftmanager.net/reunion/

and got this error
Parse error: parse error, unexpected T_CLONE, expecting T_STRING in /Users/shiftmanager/Sites/xoops.reunion/html/kernel/object.php on line 528

so your link to that drupal forum topic wont help in simulating.

I'd like to keep this on the radar, unassigning.

Question to the OP: can you provide as much details as possible for *your* situation?

I have encountered this on one of my sites and also drupal.org a couple times recently.

Login information is entered and you get taken back to the same page with an empty login box. If you leave the fields empty and click the login button again you get logged in.

I had this. I thought it was because of LoginTobbogan. I wasn't aware of the "click the button again" workaround. I finally fixed it by deleting the cookie. I bet it could also be fixed by clearing the session db. I was in a bit of a panic because I thought my database was corrupt so I didn't test everything.

I've tried to install 4.7 on localhost. Everything seems to be fine. So I transferred it to my host. It has many trouble at first but I managed to complete it. But I can't login, I don't know why. I think it's my fault so I tried to retransfer , in more safely manner, again. It still not work.

So I tried to install the clean version on my host. And It can't login either. But if I use 'Request new password' feature, I can login that way. And If delete all domain cookie, I can login.

My hosting environment:
Plesk 7.5.4
Apache 2.0
PHP 4.3.2
MySQL 3.23.58

You can try at http://test.somdee3a.com/

I have the same problem, I was also having compilation problems, but upgrading my pcre libs to 4.5 fixed that. Now, I just can't log in! =)

None of the workaround listed above work for me, not even the request a new password (no email is sent), however, email IS sent for creation of a NEW account, and the one time login works for that.

I'm running RHEL 3.0
mysql Ver 11.18 Distrib 3.23.58, for redhat-linux-gnu (i386)
apache (redhat-httpd) httpd-2.0.46-56.ent
PHP 4.3.2 (cgi), Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
pcre 4.5

update: "request new password" work around did email, but a mail filter got it, sorry.
But, requesting a new one time password every time someone wants to login is still not acceptable.

I recently encountered the "login fails to take" problem on 4.6 for IE users ONLY. For that problem, deekayen's solution (http://drupal.org/node/6696#comment-117769) worked. (The "fails to take" problem is where the user logs in, drupal believes that a session has started and updates the "online users" box, but the cookies are bad, and so the browser doesn't believe that a session has started and returns the user to the login page again. Though deekayen explains that a lot better than I can.)

However, on my new 4.7 site, I'm encountering a similar, but not identical problem. I log in with my name and password, but the "online users" box does NOT update. (My login page is the front page, so as in the previous use case, I'm returned to the same page I started from) However, if I then enter my name and password a second time, I can log in successfully. I'm running FF, so this is different from the first use case, which was only IE.

I went to look at the sessions table, and saw the following alert (triangle with exclamation point) in PHPadmin:

PRIMARY and INDEX keys should not both be set for column `sid`

Here are the fields and the indexes:

Field       Type            Attributes   Null   Default
------------------------------------------------------
uid         int(10)         UNSIGNED     No      0
sid         varchar(32)                  No
hostname    varchar(128)                 No
timestamp   int(11)                      No      0
cache       int(11)                      No      0
session     longtext                     Yes    NULL

Keyname      Type       Cardinality   Field
------------------------------------------------
PRIMARY      PRIMARY    886           sid
uid          INDEX      14            uid
sid          INDEX      886           sid
timestamp    INDEX      886           timestamp

This is from a 4.6.5 database upgraded to 4.7. In the update script, the following line appeared:

Failed: ALTER TABLE {sessions} ADD PRIMARY KEY sid (sid).

So I updated that table manually. Could this be a source of the difficulty?

I don't think the session table key is the issue. I checked my session table and sid isn't a key. (Using 4.7 fresh install.) I've also tried resetting my cookies. For me the issue seems related to POST form data not getting set.

Why would POST data not get set? Is this an apache issue?

I'm having this problem as well. I've tried all of the solutions offered in node/6696, but nothing has worked so far. The logging in twice, with or without the username and password fields empty doesn't work for me either. The only way I can log in (on both FF and IE) either as the admin or as a regular user is by requesting a new password.

I didn't have clean URLs enabled, because my server isn't configured for that. Is that my only hope? I'm not sure if my host will allow that.

I have this problem too.
And I have logout problems into firefox/opera. (And IE don't even login)

The problem probably exists in cvs, too. A fix must be found for cvs, and it will probably be backported to 4.7 soon after.

From the forum thread, it seems many people have this problem, but the majority don't.
Is this issue also related to the other issues about cookies and double login?

In any case, until those who experience the problem can tell clearly under which conditions this problem occurs, and until they tell exactly how to reproduce the behavior, there is little that can be done to fix the problem.

this issue IS critical for those who experience it, but until we have more precise information (step by step intructions to reproduce), pretty much little can be done about it.
Once you've made sure the problem is not cause by a contrib module, and you have agreed between yourselves on how to reproduce, you can then set this issue as critical.

On my site I can login 2nd time, not first time.... I am running drupal 4.7.2.... this is very serious problem for me, the client is rejecting my entire solution, till I fix this issue.

Anyone have any workarounds.

@tahert, the double login bug has just been fixed in 4.7. The fix will be in 4.7.3.
see here for details and for the patch:
http://drupal.org/node/70521

but I don't think this issue is fully related to that one, or is it?

I was not able to login at all now, I even applied the patch, did 9-10 attempts, just cannot login.

EDIT --- I applied the patch and cleared my cookies, now I am able to login in first attempt in Firefox..hopefully will work well with IE too..

I upgraded to 4.7.3 during a move to a new server, and I had the login problem with my admin account--watchdog said I had logged in, but the user page came back with the same login boxes, navigation blocks didn't change and I got access denied when I entered an admin URL manually. My mirror site at a different subdomain worked fine.

I tried truncating the sessions table with no luck. It had sid set as the primary key and index. I eventually worked around the problem by deleting all cookies for the main domain. I think there were two PHPSESSION cookies in there.

I just did a fresh install of 4.7.3 and am experiencing the problem.

I have

• deleted all other cookies
• cleared the DB cache table
• added ini_set('session.name', preg_replace("/[^a-z\d]/i", "", conf_path())); to my settings.php file

Still experiencing the problem. I started putting in a lot of debug statements to watch the value of the global variables "$user". I also watch if the user_load() function in user.module ever returns an null value or user with uid == 0. (It doesn't.)

However, in the sess_write() call, I watch the update statement and it continually writes UPDATE {sessions} SET uid = 0.... If I "print_r()" the $user variable, it is completely empty.

I don't know where or why global $user is getting set to an empty value, but it is somehow. (I wish PHP had a debugger with watch variables...)

My platform is Apache 2.2 running PHP 5.2.0 (CVS) and MySQL 5. Occurs on both Opera 9.01 and Firefox 1.5.6

Hope this helps... I've spent a lot of time on it but can't figure out why by the time sess_write() gets called the $user variable is cleared.

Finally Tracked This Down

This is a bug PHP's behavior with global variables. I have a simplified test case which shows the problem in operation and offers a fix.

This has been hard to resolve - this "login issue" can manifest itself from other bugs that involve session ID's and cookies. This is yet another issue.

Quick Fix

Change Drupal's index.php so that last couple of lines become

drupal_page_footer();
$GLOBALS['tempUser'] = $user;

This creates a copy of the $user object and coerces the PHP engine to recognize the stdClass object inside Drupal's sess_write() function.

Problem Background

Without the above fix, PHP is not importing stdClass global variables into the sess_write() function. This is incorrect PHP behavior; your server's OS and PHP build influence whether or not this shows up for you.

When Drupal gets to the sess_write() function (one of the last actions it takes for a page), it updates Session information based on the current $user object in global scope - namely, it uses $user->id in its updates of the session table.

Since $user isn't define in the function's scope, it uses a default of 0 which causes the correct session information to be present but with a userID of 0 (anonymous), which sends the user back to the login form.

I don't know PHP engine internals, but putting a duplicate of the $user variable directly into the $GLOBALS array fixes it (for me).

(Incidently, it looks like this bug plagues other CMS's as well - I saw at least one thread for Joomla with users experiencing similar problems.)

Reproducing the Bug

I've attached a .zip file of a PHP script that demonstrates this behavior. If you are on a server with this problem, run the script as-is and you'll see the (wrong) behavior demonstrated. (Look for the 'user' variable to be present in the $GLOBALS array.)

Uncomment the line so that a copy of the object is put into the $GLOBALS array and run it again - you'll see both object appear in the sess_write() function.

I was doing this on a fresh install of Drupal 4.7.3 on

• PHP Version 5.2.0RC2-dev
• Apache Version: Apache/2.2.3 (Win32) PHP/5.2.0RC2-dev
• OS: Windows 2k3 Server SP1

Help Needed

To help track down when and where this bug is occuring, we'll need information about the platform and build of PHP that you're on, and not just your client OS and browser. My guess is then we'll start to see a pattern emerging.

(If a pattern doesn't emerge, it may be down to the level of individual PHP modules that are loaded, but I doubt it.)

If my analysis of all of this is correct, this isn't a bug that Drupal authors can fix - it needs to be submitted to the PHP/Zend people to fix. (Drupal authors can add in this work-around, or at least make this fix more public.)

I've seen the problem rife within this config:

Operating system Linux
Kernel version 2.6.9-22.ELsmp
Machine Type i686
Apache version 1.3.36 (Unix)
PERL version 5.8.5
Installed Perl Modules Click to View
PHP version 4.4.2
MySQL version 4.1.21-standard
cPanel Build 10.9.0-RELEASE 34

As far as I can tell, (and I'll followup if it isn't) the $GLOBALS['tempUser'] = $user; fix seems to have resolved the issue. If it doesn't I am very sure the user base who was waving sticks at me yesterday will continue today. However logging in and out with new and different browser configs seem to not show it. If this is a fix then I am so very grateful since I was at my wits end trying to track it down on our host DWHS.

I have experienced strange login phenomena which I tracked down to inconsistent use of the www prefix on the domain name. It seems that a different set of cookies are in use for www.domain.com than for domain.com. Sometimes the login page would allow me to log in, but then direct me to a page on the other domain, which of course I was not logged into. I don't know if it part of the problem being discussed here, but it certainly is a related issue.

Don't change the title.

It seems that a different set of cookies are in use for www.domain.com than for domain.com.

this is just the way cookies are, please do not litter this issue with reports on this (another issue was torn apart with stuff like this).

JamesVL, what you are saying is extreme interesting. I will look into this & report PHP bug if necessary.

I am well aware that cookies work like this. That is not the issue.
The issue is that Drupal was effectively switching domains after login, to the parallel domain in which the user was not logged in, resulting in an apparent double-login problem.

Eaton took the effort and the cost to set up a DWHS account and I set up a Drupal there and can't repro. Please contact me with access to a server where the problem surfaces.

I have spent a couple of hours trying to reliably reproduce this. First: it happens with Firefox, but not IE. With IE you can log into domain.com, switch to www.domain.com and you are still logged in. In Firefox you are not.
I have examined the logs after the problem has occurred and even though the user tried logging into domain.com, the log says they logged into www.domain.com and then instantly logged out. The browser is redirected to the www domain.
As soon as I can reliably reproduce the problem, I will make my server available to you.

I can only reproduce this problem as an artifact of the particular developement environment I have set up, with multiple browser windows on the same Drupal account. It is highly unlikely a normal user would encounter it. Sorry for wasting people's time!

I am witnessing a situation which may be related to this issue and may help in finding a resiltuion.

I have a Drupal installation on a host which can be reached via browser by either http://domain.com or http://www.domain.com. I can login into the site through http://domain.com without any problem, but not through http://www.domain.com (the login block comes up on page refresh, without any notification, as reported by others). Though, there are a few things that puzzled me:

1. If I login through http://domain.com, close the browser without logging out, open the browser again and point it to http://www.domain.com then I continue to be logged-in and can access the site without any problem.
2. If I log out from http://domain.com, delete all the cookies and then visit http://www.domain.com and login then the login SUCCEEDS. Logging out and logging in to http://domain.com also SUCCEEDS (ie; login to http://domain.com always succeeds but login to http://www.domain.com succeeds only when there are no cookies for http://domain.com)
3. The above observations are with IE6. With FireFox, login through either of the URLS, http://domain.com or http://www.domain.com succeeds. I even tried a number of sequences of login and logouts in different permutations and all work fine.

Makes me feel that there is something weird going on with cookie handling!

I am going to agree with chx on this: the cookie/domain issue can also cause login issues, but the bug I am describing is not related to that particular problem.

This is a PHP server configuration issue - your host's OS and PHP build will make a difference.

For instance, I've run into this bug on PHP 5.1.4 and PHP Version 5.2.0RC5-dev running on Windows Server 2003.

BTW, this issue still crops up in Drupal 4.7.4 for me...

I just upgraded to php5.2.0 and so ran into the php bug JamesVL already found. JamesVL quickfix fixed it for me..

JamesVL, do you know if the php people are aware of this bug? I did a quick search but I wasn't able to find a related bug report.

hm, the workaround fails sometimes if data is sent through POST.

for more details on the php5.2 issue see http://drupal.org/node/92802

Perhaps this should be added as a new bug, can get lost in all the news in this one!

One reason administrators can't log in at the beginning is if the admin user's uid in the users table is not set to 1. This can happen (as in my case) a user tries out Drupal, then later upgrades to a new version of Drupal, using the same database. Even if the administrator user record is deleted, the auto_increment is still set to 2,3 etc, and one always gets the 'Access denied error'.

To fix, when creating the first account, the first uid in the users table should ALWAYS be set to 1, and should not rely on the auto_increment. If setting uid to 1 is not possible (already populated), an error message should be generated.

Just hit this myself and managed to fix it, it seems. Repeating what I said here:

Added this to my settings.php:
ini_set('session.cookie_domain','www.mydomainhere.com');
ini_set('session.auto_start', 0);

Just piping up to say I hit this "attempt login but just returned back to the page without an error but not logged in" problem in the past couple days on my Drupal 4.7.6 setup after it was working flawlessly for 4 months since Drupal 4.7.4, and the above seemed to have fixed it. I've tried many of the other suggested fixes on this page before this one, though (too many for me to remember...).

O.S.: Debian 3.1 Linux
Server: Apache/2.0.54
PHP: PHP 4.4.4-0.dotdeb.1 (CGI)

It just seems strange as this was a pretty sudden problem. The only thing I remember doing is telling my VPS host to up my RAM and Hard drive space, but it would seem weird if that triggered it. The Drupal 5.1 setup I have on the same server doesn't have issues with logging in.

I have an interesting take.

I've just started with Drupal, so bear with me.

I recently installed, and learned how to create a backup by creating a subdomain, creating a backup database, exporting and importing the database, etc.

As far as I can tell, I have achieved an exact replica of http://www.thepulse.ca at http://dev.thepulse.ca, for development purposes.

Here's the interesting part. There's a machine at the office running IE6 that won't log on to dev.thepulse.ca, but WILL log on to www.thepulse.ca. All the machines are running IE 6.02.2900.2180. The "problem" machine has more "settings" I'm not going to touch.

Figure that one out! It can't just be about local settings, because they work on one of my sites. But why not the other?

Hope this helps the effort, and good luck.

I'm running 4.7.? at Site5

Modification to above post - I've looked at it on five other IE6 machines in the office; I use a Mac. My old PC on IE6 also works.

After upgrading from mysql 4 to mysql 5, this problem occurred to me as well. By rebuilding the "sessions" database, everything fixed itself.

Here's is what I did:

Log in to myPhpAdmin (for mysql)
Choose your database you are using for the problem drupal installation
select the "sessions" table
You may be informed with a warning that "sessions" table is corrupted and needs to be rebuilt
if so, then {
click on the "empty" tab on myphpadmin
You will be presented with a confirmation js popup "are you sure you want to empty the table "sessions"?"
Click "OK"
}
The "sessions" table is emptied which also generally repairs the corrupted data.

Your site will allow you to log in now.

Joe Hyde

Interesting. I ran into this problem only after adding a multi-site installation. No issues with the original Drupal instance but the second instance (set up as a same-code subdomain with a separate database) wouldn't let me login. After adding the $GLOBALS line suggested above I found I could login after a password reset but only for one session... when working in Firefox.

** Then I discovered that Opera works just fine. ** I can log in and out at will. This is true with or without the addition of the $GLOBALS line in index.php. It makes no difference to Opera.

Here are my relevant specs:

Host:
bluehost.com (Shared host)
Drupal: 5.1
Apache: 1.3.37
PHP: 5.1.6
MySQL: 5.0.27

Client:
Gentoo Linux
Browser:
. Firefox 2.0.0.6 (only allows one-time login after pw reset)
. Opera 9.22 (works just fine)

The 4.7 version is not supported, but the last comment is about Drupal 5. So, maybe the issue can live a little bit longer..

I have two nearly identical sites setup-wise. I could login to one but not the other. (On the problem site, I could login from pages other than the homepage.)

As it turns out, the difference between the sites was that the problem site had these lines at the top of the .htaccess file:

RewriteEngine on

RewriteCond %{HTTP_HOST} ^mysite.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.mysite.com$
RewriteRule ^front_page$ http://www.mysite.com/ [R=301,L]

RewriteCond %{HTTP_HOST} ^mysite.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.mysite.com$
RewriteRule ^node/1$ http://www.mysite.com/ [R=301,L]

I added and removed different modules to each site along the way. I had front (front_page) on the problem site but then disabled it. I assume one of the modules added the lines but did not remove them when it was uninstalled. Searching the code for "RewriteEngine" in my current installation, I do not find anything.

ccode

Problem is still there in the latest version. I don't know how this happens. The DRUPAL_UID cookie is set twice in a http response. Screenshot attached.

I'm using the latest Pressflow 6.19.92 and nginx as reverse proxy. But I don't think it is irrelevant, as many users report bug here and in [#6696] (well, I admit I haven't completely read that discussion).

And even if Drupal is force to send cookie twice, this is a PHP/browser related issue?

Reverting the status. Sorry, DRUPAL_UID is boost specific, not in core. Discussion #253932: Logged-in-users get logged-out erratically