I have two D6 installations on the same server. They was working fine, but the server on which they were running had a disk failure, so the installation was moved to a newer server. On the new server, the Drupal sites appear to display fine (I have two different sites under separate installations). However, none of the users can access the admin pages.
When I log in with the correct credentials, I get an Access Denied message on the subsequent user page. The authentication appears to be successful -- if I enter incorrect credentials, I get an incorrect credentials message.
After login, and after the Access Denied message on the user page, if I then manually navigate to an admin page, I am still greeted with the Access Denied message, as though I'm not logged in.
phpMyAdmin runs fine on the server. A custom (non-Drupal) PHP web app with PEAR-based authentication runs fine.
I have examined my php.ini file -- with the exception of changing some basic parameters (max post/upload sizes, location of MySQL socket), it's fairly in line with defaults. MySQL seems to be configured fine, mostly default. I am on Mac OS X Server, using a custom MySQL installation through MacPorts along with the OS-supplied PHP / Apache setup. As for client-side, I have completely reset Firefox and cleared cookies/cache from Safari -- I see this behavior on Mac / Windows and Safari / Firefox / IE. I have truncated my Drupal sessions table. The settings file has a cookie domain set to accept the default.
I am at a loss as to why both Drupal installations are exhibiting this behavior. They use some of the same modules, but their setups are not identical.
I really can't seem to identify what I should be looking for when trying to figure out why my sessions aren't recognizing that I have successfully authenticated. Does anybody have any suggestions for where I should be looking?
Comments
A shot in the dark
This is really a shot in the dark, but since you seems to be up the proverbial creek, I will suggest a few things.
First, examine
.htaccessto make sure that it is not Apache blocking access.If you're sure
.htaccessisn't the culprit, open upsettings.phpand look at the section "Base URL (optional)". Uncomment the line to set$base_url(replacing example.com with whatever is appropriate for your site).You may also find something here: http://drupal.org/node/228587
No luck so far
Thank you!
I took at look at your suggestions. I can add a few more notes now after trying those.
I don't see anything in .htaccess other than the default options. I tried the settings.php tweaks, including the register_shutdown_function, no luck.
Here are some more things that make me think I am somehow missing something on the server itself.
I have installed a new copy of D 6.26 as a new site and new database -- I get the same problem. The installer runs, and then I immediately get Access Denied. I give the web user full permission for the web directories during the install.
I have copied the site to another server, and it works fine.
So, in respect to that last note, I am now trying to run this on Mac OS X Server 10.8. It was previously running fine on Mac OS X 10.6. Also, the server to which I moved it is an Ubuntu install, so it's running fine there as well. I am desperate to try to get it installed on the Mac OS X Server because it is the hardware we have locally.
Because of this, I think there must be something I'm missing.
The Mac OS X installation is running Apache 2.2.22, MySQL 5.1.66, and PHP 5.3.15.
The Ubuntu machine is running Apache 2.2.11, MySQL 5.1.31-1ubuntu2, and PHP 5.2.6-3ubuntu 4.6
I am looking at Drupal 6.26, 6.24, and Drupal 6.22 all resulting in Access Denied.
One last thing -- it seems that, on the Mac OS X installation, in the sessions table, I am getting a bunch of sessions for myself. However, on the Ubuntu installation, I only get one session for myself.
Mac OS X
So, clear my sessions table.
Visit http://new.site.com/user
Get a session ID with uid = 0
Log in
Get a new session ID with uid = 1
Old session ID with uid = 0 still in sessions table
Ubuntu
Clear my sessions table
Visit http://www.site.com/user
Get a session ID with uid = 0
Log in
session ID is now updated with uid = 1, no additional sessions for my host in the table
The site is not redirecting somewhere else when logging in -- it is not utilizing securelogin or anything like that at the moment (those are disabled). Although right now I am trying to coordinate this by using a separate subdomain, "new.site.com", this problem existed when I was trying to log in with no modifications other than the move to the new server.
I don't know if any of that causes any lights to go off -- it seems to me that the multiple sessions for my hostname, when I don't see the same behavior on the Ubuntu installation, would point to something problematic with the way sessions are being handled.
You could try truncating the
You could try truncating the cache tables.
Also, look to see if any tables are marked as in use or in need of repair.
Found the problem! Wrong SID length!
Thanks for those suggestions -- I hadn't tried truncating the cache tables. That didn't work, but it caused me to pay more attention to the sessions table as well (since I tried truncating that again).
In the past, I had noticed that my sid seemed to match when looking at the value in Firefox and in the sessions table. However, viewing the ENTIRE sid Firefox, I realized that MySQL was truncating the sid. Drupal is set for a VARCHAR(64) field for the SID, and something about the way the SID is currently configured on the server is causing the SID to be too long. Changing the field value to a VARCHAR(128) fixed the problem!
I will review the PHP.ini file and make the change there, instead, to shorten the session ID if possible. But, for now, at least I know what the problem is.
Thanks for your help in getting me to nose around in the right area!
I think I am having the same
I think I am having the same exact problem.
How exactly did you make the fix?
I'm no programmer.
Thanks.
worked for me
I had moved my Drupal 6 site to an internal Mac OS X 10.8 server and changing the length of the SID to 128 worked for me as well. It appears that this only happens with Drupal 6 and not Drupal 7.