Hello,

I am having a strange issue with my site. I cannot access any of the administrative areas of the site any longer. Everything was working just fine about a week ago, when I upgraded to version 6.16 now I want to upgrade to version 6.19 but I cannot seem to log into the site properly.

My issue is that I get and Access Denied page after I log in. I usually log in by going to:
www.myurl.com/user

After a successful login, it redirects me to:
www.myurl.com/user/1

Normally, I would see my user info, but now I just get the access denied error. I get this error when I try to manually get to the admin pages at the '/admin' url.

I know I am using the right user/pass becuase if I enter the wrong password on purpose, I get an error message telling me my user/pass don't match. Also I am displaying the "Who's Online" block and I can see my username on there numerous times, evey time I attempt a login, it add the same username to the list again and again.

Any help would be greatly appreciated,

Thanks,
Rob.

Comments

bsenftner’s picture

I just went through this same nightmare yesterday. I have no idea what was the cause, but thank gawd I use the "backup & migrate" module...

I ended up, after multiple restores, upgrades and always ending up with a user/1 login receiving 'access denied' for any admin pages, doing a fresh install to fit things.

I deleted my entire document root, including any hidden files such as .htaccess and .sites and doing a purely clean install. Finally that behaved normally.
Then I moved my contributed modules back into place and enabled all of them except for the Masquerade module (I suspect that one caused my problem).
Then, with "backup and migrate", I restored my last backup and everything was happy again, with the 6.19 release.

PITA!!!

allartk’s picture

try to remove your cookies, it helped me

bsenftner’s picture

I did all that, cleared the browser cache & cookies, being unable to clear the site's cache because I had no admin access I did my cache clearing and session table clearing via phpmyadmin thru my hosting interface. It was not until I installed completely fresh with an empty database (removed all tables) and no files (not even hidden ones) in my html document root did I get normal behavior back. Thank gawd for backups...!

rkolech’s picture

Thanks for your reply guys, I was hoping I would not have to do a fresh install, but it looks like I may be out of luck here, I have backups of everything so nothing will be lost (I hope) and the site content is mostly empty at the moment, but I have spent lots of time setting it up so it would be great if I could keep my settings intact.

I also tried entering a bad password and then clicking the forgot password link, and sending a password reset e-mail, this did not help the issue either, still getting the access denied error after I click the log in button. :-(

How do I manually clear my cache using using phpmyadmin? I count about 11 tables that start with the word 'cache' in my Drupal DB, do I just clear these tables out? Thanks for the help.

dmoore’s picture

I had exactly the same issue (which only affected Firefox). Even though the release notes seem to make light of the change, it seems that if you are using Firefox you have to set a $cookie_domain in your settings.php file.

I changed my $cookie_domain (which was previously commented out) to the following - and all worked perfectly:

$cookie_domain = $_SERVER['HTTP_HOST'];

rkolech’s picture

Thanks dmoore,

That got me going, I did not try logging in using IE, but that worked fine. Once I changed my settings.php file, Firefox works as well. I was just about to nuke everything like suggested above, but I am glad I waited a bit.

rkolech’s picture

Ok it seems I spoke to soon. I am able to log into my site from both IE and Firefox only when I comment out the line:

$cookie_domain = $_SERVER['HTTP_HOST'];

in my settings.php file. If I leave this line in, I get the same access denied error in both IE and Firefox. I am running Drupal 6.19 at the moment. Now all works well with this line commented out but I do get the following warning on my status report:

CKEditor	3.2
You are using a feature that requires $cookie_domain to be set, but it is not set in your settings.php (CKFinder is enabled in the Advanced profile). 

I have tested out CKEditor and CKFinder and both seem to work well despite the warning. I think I will leave it like this for now with the line commented out, and see if future versions of Drupal will go back to 'normal'. Thanks for all your suggestions, luckily I am log in again!

kndr’s picture

Try this:

In settings.php set appropriate domain (with www)

$cookie_domain = 'www.mydomain.com';

and in .htaccess file uncomment two lines and set:

RewriteCond %{HTTP_HOST} ^mydomain\.com$ [NC]
RewriteRule ^(.*)$ http://www.mydomain.com/$1 [L,R=301]

It works very well for me.

billspreston’s picture

I've been having a similar problem and fixed it with this:

$cookie_domain = '.mydomain.com';

Anonymous’s picture

I thought I'd cleared cookies, by clicking the "clear cache" button in Firefox, turns out, that isn't good enough for this problem. I eventually used this: https://support.mozilla.org/en-US/kb/delete-cookies-remove-info-websites.... Browser-specific solution I realise but, hopefully gets the next person thinking about clearing cookies properly.

serverjohn’s picture

I had the same problem with Chrome. Clearing the cache help me too. :-)

Thank you!

jimrockford’s picture

Background:
I migrated my prod back to my dev. tar'ed up my drupal filesystem and copied it to dev. mysqldump prod db and restored it in dev. copied my nginx config, php config, php-fpm config, etc, all to dev. After changing several env-specific configs, mainly file paths, and setting all www.mydomain values to "localhost", it all fired up just fine.

But, for the life of me, I kept getting access denied at login, yet sessions were appearing in the sessions table.

I followed this thread and others, tried a few things, but still no luck. Then, I set the following php.ini configs as follows (yes, not commented out, rather set to nothing):

[php.ini]
session.cookie_domain = (yes, not commented out, and NO value after equals. it was set to "localhost", that didn't work)
session.cookie_httponly = (yes, not commented out, and NO value after equals. it was set to "1", that didn't work)

My other settings are as follows:
[settings.php]
$base_url = 'http://127.0.0.1:40598'; // my nginx port #
#$cookie_domain = // commented out
[nginx.conf]
server_name 127.0.0.1 localhost;

kcrackerg’s picture

This error was driving me nuts and your solution worked for me also. Thanks for the post!

the_g_bomb’s picture

I have had the same issue just occur on a couple of development sites. All sites on my dev server have been recently upgraded to drupal 6.19.

Some sites (the ones I am currently working on), I have just noticed have had this issue where Access denied is shown to users logging in through Internet Explorer only. I have tried all the various fixes changing the cookie_domain etc. to no avail.

I then looked a bit further and some older sites work and some older ones don't. The problem was really bothering me, not because I couldn't log in through IE, but because some sites do work and some don't. Tried disabling any modules that were different on the sites, did compares on the files, settings and other configs referring to the sites that worked and those that didn't.

The only difference I could find between sites that do work and those that don't seems to be in the domain name.

My dev site are all accessed through mysite.dev.mydomain.com, the ones that don't work seem to include an underscore. i.e. my_client.dev.mydomain.com, the ones that work don't have the unscore i.e. aclient.dev.mydomain.com.

Changing my_client.dev.mydomain.com to myclient.dev.mydomain.com fixes the problem. No other changes required.

--
G

bsenftner’s picture

Thanks for your discovery information. Worth keeping in the voodoo bag of tricks.

zterry95’s picture

I encounter the same problem.

fixed by remove the "_" in domain.

It is very strange.

marblegravy’s picture

Still no idea what really fixed it but none of the suggestions above worked. The clue for us was that only *some* machines were affected.
The fix was to do a hard reset of IE's settings on machines that were being affected:

  • In Internet Explorer, go to Tools -> Internet Options
  • Go to the Advanced tab and click on the Reset button
  • On the Reset Internet Explorer settings window, tick the Delete personal settings box and click the Reset button
  • Now close and re-open Internet Explorer and you should be able to log in.
batigolix’s picture

If your site has a short 4 character domain name (e.g., "ab.be") domain then this might be caused by a IE bug . See #280623: Problem with 2 letter domain names, Internet Explorer and cookies

jurveen’s picture

I came across this strange phenomenon after moving a Drupal 7.15 site from the test to live server.
Test server: login with any browser works normal.
Live server:
- login in Firefox, Safari, Chrome... works normal.
- login in IE with the same valid account: it shows the url [mydomain.com]/user/15 and 'Access denied'.

I cleared Drupal caches, truncated the sessions table, full reset of IE. Nothing works!
Any suggestions? Thanks in advance!

Update: I reread the whole thread, and the solution of the_g_bomb worked. Turned out that the underscore in the subdomain was evil... Doh.

le dendrite’s picture

I was having this trouble also. After reading through a lot of the comments and attempting various fixes with no success, I decided to try something and it seems to have resolved the issue. Not exactly sure why, maybe someone else will have that insight...

All I did was change the password in settings.php to something invalid, causing the site would crash.
Then I changed it back to the correct password again.
Refresh and use password recovery.
Success, the link from the recovery email successfully brought me to my edit user page.

Drupal 7.22

**** Update ***
Issue is randomly back, and my previous fix has proven to be a coincidence I guess.

*** Update ***
Alright so the following finally worked for me.
As Noted in settings.php "Make sure to always start the $cookie_domain with a leading dot, as per RFC 2109."

$cookie_domain = '.MySubDom.MyDom.com';
$conf['https'] = FALSE;

Specifying the $cookie_domain in any other way was not working for me.
Hopefully this fix sticks.

jgullstr’s picture

For future reference: I had this issue on a D6 install. The reason was that the session table had been corrupted due to lack of disk space. Running

REPAIR TABLE sessions;

on the database resolved the problem after clearing up some space.

vladsh’s picture

In my case when I tried to execute in PhpMyAdmin
REPAIR TABLE sessions;
I saw a message

#1142 - INSERT command denied to user 'my_username'@'localhost' for table 'sessions' 

It happened because my shared hosting provider just had restricted write to my database due to the overlimit of disk space at my account.

sarathkm’s picture

Corrupted session table issue was problem D6 running site here.

halth’s picture

What worked for me was enabling and configuring the $cookie_domain variable in settings.php (because I have a site that can be accessed by 2 different domains).

Pay attention to the comment before this variable! The domain name must start with a period. EX:
$cookie_domain = '.example.com';

Good luck!

--
Heitor Althmann
Drupal Developer