Drupal 7 Access Denied user/1 after correct login

By TaylorDigitalChris on 14 Jan 2011 at 22:10 UTC

For some reason, I can't seem to login into my localhost (windows 7 + apache) Drupal admin account. I know I have the correct password since validation tells me when it is not correct. I believe it might be a session issue and I tried clear my sessions but that didn't work.

I looked at my sessions table and each session has no SSID. I don't know if that matters.

What is the best way to reset admin to default settings to fix this issue? I have made a lot of modifications and I don't want to loose them.

Comments

try this

bawoor commented 14 January 2011 at 22:54

try this
http://drupal.org/node/68286

ꦱꦠꦽꦶꦪ

I have the same issue... (Sorry to bring up an old thread)

carlwhittick commented 31 January 2011 at 14:45

I was working on a Drupal 7 theme and I got logged out (No idea why). Now when I attempt to login I get a Username/Password incorrect error even though I logged in with the exact same information before. Since that failed I have re-hashed myself a new password using the shell script provided in the "/scripts" directory, inserted it into the database and am still getting the same error.

Any help would really be appreciated.

Cannot login either

4x3 commented 2 February 2011 at 16:11

Anyone find a solution to this?

Having same issue, logged out as admin, then when trying to log in I get the access denied page - only in Firefox. I am able to log in through Safari and on other computers.

Still not working.

bigonroad commented 21 February 2011 at 14:23

Any ideas guys? I have rehashed the password, but its not working.

Currently can't log into my site!

(Grr)
Chris

Aha

bigonroad commented 21 February 2011 at 14:41

In the end, I logged in as another user, then logged in again as user 1 and it worked.

No idea why...

your admin passwords

bawoor commented 26 February 2011 at 00:51

your admin passwords automatically saved by firefox. if you're not log-out normally this password is still store and locked. trying to clear all firefox cache to new login.

ꦱꦠꦽꦶꦪ

Issue resolved.

Rahul Seth commented 1 December 2014 at 12:04

Thanks @Aha, I faced the same issue but after logged with another user, I tried to loginned as admin. And it worked. I think it's browser issue.

Tried

rajeevkumar commented 24 March 2015 at 04:53

Hi bawoor
I tried this but its not working. Any other way to resolve this ?

YMMV

Screenack commented 15 March 2011 at 15:33

D7: I had this problem, and I knew it would be simple to fix. And it was, once I wrapped my mind around it.

I'm using ckfinder and I have to define a cookie path. I had defined it locally but not for the new hosted domain. I updated that and boom! I'm in.

Thanks to this simple reminder here: http://nice3z.myfinejob.com/unable-login-drupal-access-denied

The author mentions base_url, but that triggered my recollection of updated paths in my settings file. (Interestingly, this error will not throw an error to the log, since, nothing's wrong, really)

Perfect

yooperjb commented 29 June 2011 at 19:47

Kyle,

Thanks a bunch for that solution, worked perfectly. At first it didn't work until I cleared my browser's cookies and then all was well.

Thank you so much, that was

zielwasser commented 7 December 2011 at 13:46

Thank you so much, that was very helpful!

saved my day

kobever commented 23 December 2012 at 20:17

worked!

This fix worked for me. I am

hockey2112 commented 18 April 2013 at 15:08

This fix worked for me. I am in the process of duplicating a D7 site for a client who needs a econd site with similar branding and data. Once I changed the cookie domain in the settings.php file, my problems were solved!

i have the same problam i

Kristofivan commented 22 May 2013 at 17:28

i have the same problam i cant log in to my site in the normal way (only with Request new password) althought I know the correct password and username......

Can you please explain a bit more detailed what do you mean by: "Once I changed the cookie domain in the settings.php file"

Thx,
Kristóf

Note: be wary of setting $cookie_domain = $_SERVER['HTTP_HOST']

davmorr commented 6 June 2013 at 19:18

There is a config setting in the settings.php file: $cookie_domain
Set that to your base domain host name: www.yoursite.com
You can also share a base domain to accommodate multiple subdomains: .yoursite.com
There are relevant comments in settings.php file.

NOTE: if the $cookie_domain value is set to $_SERVER['HTTP_HOST'], which some admins do as a shortcut in the 'sites/default/settings.php' file to make the code base more portable between site installs, you would be advised to set this to the hard-coded host domain name. The reason for this is that on some sites, esp. local dev site installs, may have a port number appended to the domain name, which is picked up in the $_SERVER['HTTP_HOST'] var value; i.e. www.yoursite.com:8080

The port number WILL break the cookie set process, which will defeat the authenticated session upon login redirect since authentication is tracked across pages via cookies. Super frustrating if you don't know what to look for, as nothing necessarily looks wrong with this - $cookie_domain = $_SERVER['HTTP_HOST'] - when doing a general troubleshooting and debugging review trying to find the cause of the authentication error.

I figured this out the hard way after stepping and digging through code and process validations over the course of at least one work day, when I pulled down a site code base and database from a staging server to fix unrelated issue items. Apparently someone recently changed the hard-coded domain value to the global $_server['http_host'] var. This looks legit when doing code review, trying to isolate where the authentication is breaking, and there is nothing technically wrong with this approach. The only real problems with this approach are that 1) the $_server['http_host'] value is not guaranteed to work with Drupal's cookie processing, and 2) that its validity is deceptive, as in it 'looks' like it should work, making it easy to skim over and dismiss as the cause of this bigger issue.

This works for me .Thank you.

deerta commented 1 July 2013 at 22:44

This works for me.

I had switched from Hostgator

flatfeat commented 8 July 2013 at 02:52

I had switched from Hostgator to a test domain in Rackspace, and had my old domain on the $cookie_domain line in settings.php. Commenting it out is what made this work for me. Thanks.

Thanks a lot for digging into

Swarnendu-Dutta commented 17 February 2015 at 18:23

Thanks a lot for digging into this.
Finally i now know why it happened.. :P

~Swarnendu Dutta

Thanks

Sushil Kumar Sharma commented 3 May 2016 at 06:42

Thanks
It works for me.
There was $_SERVER['HTTPS'] = 'On'; in my settings.php. In this way you need to disable and login by admin.
Clear you site cache,if you change your domain name or site URL.

Thanks for posting the

krisrobinson commented 25 August 2013 at 08:50

Thanks for posting the solution, my problem was CKFinder cookies too.

thank you

_ch4ng3d commented 29 April 2011 at 10:33

Kyle Skrinak's suggestion solved the problem for me.
Awesome, thank you!!!

Drupal 6 Logs in user1 but not able to make changes

johnflyersmith commented 9 June 2011 at 14:27

I have a fresh install of Drupal 6 on a new machine. I can install a site, but can not make changes or make content. When I look at the database there are no changes. I can change the database from phpmyadmin. Also, tried root db user in settings.php.
PHP 5.5, MySQL 5.3, IIS7, server 2008

I Had the Same Problem. It has to do with the performance cache.

iris28349 commented 10 September 2011 at 01:21

The cache on the website, in the performance setting had a hiccup. Since I set the maximum page age to the oldest: one day, I had to wait one day to log in again since my last successful attempt. That did the trick. Nothing drastic necessary.

I may consider shortening the maximum page age to something a little shorter if this happens again.

Suggestion to Drupal Developers: make sure the maximum cache age isn't too long so problems like these have a solution. If it were unlimited or several weeks, it would be a disaster.

$cookie_domain

sillygwailo

Toronto, ON

commented 1 October 2011 at 07:40

This happened to me. After copying a live site to my local environment, I couldn't login with the #1 account with what I knew to be the right password. The login would appear to work, redirecting me to the right page, but showing an access denied error. The solution was to comment out the line in the localhost's version of settings.php that started with $cookie_domain = since it was set to be tied to the domain it was originally on. I also commented out the line starting with $base_url = for good measure.

(Username formerly my full name, Richard Eriksson.)

This solution worked for me

Anonymous (not verified) commented 16 January 2012 at 12:38

This solution worked for me thanks Sillygwailo - just had to flush all caches and login again. done

$cookie_domain (within

attheshow commented 13 November 2012 at 21:23

$cookie_domain (within settings.php) was the problem for me as well.

access denied for all users after server crash

Stoob commented 5 October 2011 at 18:46

Our server went down, had to reboot. After reboot, no user could login. Always received "access denied" message.

Solution was to truncate the sessions table.

(or whatever your prefix is)

HTH

A functional equivalent to this worked for me.

leistiko_texvet commented 9 January 2014 at 16:27

Our issue:
We have a Drupal 7 website. A user was unable to log into his account from Internet Explorer. I was able to log into their account with Chrome and Safari, but not Firefox (I did not try IE, as I'm running Mac OS X.). The situation persisted after clearing all caches on the site and running chron, after resetting the user's password, and after clearing Firefox's browser caches and cookies.

It's worth noting that I've seen similar login issues from a few other users... Enough to suspect that this was a system issue and not user-specific. So I asked Google...

Steps to Resolution:
I found this post, and using this knowledge, I was able to fix the situation through the standard Drupal admin interface (Bonus: I also "fixed" a setting left by my predecessor in this position.).

On our Drupal site, on the Statistics admin panel:

http://texvet.org/admin/config/system/statistics

..."Discard Access Logs Older Than:" was set to "Never."

I did the following:

Changed "Never" to "4 weeks" and saved that change.
Ran chron, waited a few minutes and got a timeout error page.
Reloaded the page, waited some more, and got a normal Chron admin page with the "Run Chron" button.
Ran chron again, waited about two minutes, and got a normal "Here's what happened after running chron" report page.
Used Firefox to try logging in with the user account that was not logging in and it worked fine.

I figure the timeout happened because it was busy purging a load of old records.

Bonus for doing it through the standard Drupal admin interface: I changed the setting that was causing the system to save too many records in the first place, so this should not recur (Here's hoping!).

Let's hear it for a shared knowledge base! Woot!

Boom!

odyseg commented 9 May 2012 at 00:36

Thank you very much! At first I thought I has something to do with my .htaccess file. I once had it to setup the inclusion of 'www' for my domain. I log out to my site not knowing in the end that I will have the difficulty to enter my site! I am entering the correct credentials but it always give the access denied label under /users/myname. The same when I try to request reset password.

Thanks again, your a life saver :)

I had this problem after

endless_wander commented 21 April 2012 at 00:35

I had this problem after copying a site from a live db to a local one.

I found running the update.php file solved the problem for me. No updates were done, but after running, my site started working again.

I'm running into this same

Po3t commented 21 April 2012 at 18:47

I'm running into this same problem now. This is the first time I've tried accessing my admin account (user/1) from a different computer and I get access denied every time I try to log in. The only way I can successfully log in is if I reset my password every time. I can log in no problem with other accounts.

I've cleared my browser's cookies, I've cleared all caches, I've even manually set a password through MySQL. Nothing seems to be working. I'm currently trying to login while I'm on vacation in the U.S. when I originally created the account in Vancouver, Canada. I can't imagine that it would have an issue with attempting to log in from a different region.

Once I login after a password reset, I change the password, save everything, and then I log out, attempt to log back in and it fails. This is all happening on a live site, not a local installation. I've never encountered this problem before, so I can only assume it's a problem with logging in from a different machine and in a different region. Anyone have any other solutions to this issue?

I just have the same

akira commented 7 May 2012 at 07:15

I just have the same problem. I need to 'Request new password' all the time before 'Log in' process.
it just happened two days ago after i changed previous Password.

Any Solutions ?

fixed

akira commented 7 May 2012 at 07:54

Solution is: i truncate 'flood' table

This is the best solution.

jessicakoh commented 9 February 2015 at 06:36

This is the best solution.

Your login is being blocked as spammer/bot.

Merci pour la réponse.

haythem_emerya commented 25 April 2012 at 16:07

Merci pour la réponse. j'avais le même problème et en suivant votre solution sa fonctionné.

weird problem - solved without knowing how

kip stanning commented 1 July 2012 at 12:26

similar problem, on several pages access denied for user no. 1. went to admin/people/permissions checked all permissions for administrator (create content, delete content, etc. were unchecked), saved permissions and all admin links reappeard on head of page (administration_menu).

regards from vienna forest
karl

politiktraining.at | politiktraining.net

Broken Sessions Table

quessity commented 28 August 2012 at 16:01

Repairing a broken sessions table fixed this problem for me.

This is the only solution that worked for me on Drupal 7

mareshal commented 24 September 2012 at 12:47

Taken from this post :
http://drupal.org/node/1023428

Execute the following commands from the command line, in the Drupal root directory:

./scripts/password-hash.sh newpwd

or for Windows:

php .\scripts\password-hash.sh newpwd

Of course, change "newpwd" to the desired password. If the password contains special characters such as a space, * or ? you must escape them, or wrap the password in quotes appropriate for the shell used.

The script will output a password hash that is valid for the site. Copy this to the clipboard or write it down somewhere; you'll need it for the next step. Be careful not to include more or less characters as the hash. These hashes look somewhat like $S$CTo9G7Lx28rzCfpn4WB2hUlknDKv6QTqHaf82WLbhPT2K5TzKzML

Then execute the following query on the Drupal database:

UPDATE users SET pass ='thepasswordhash' WHERE uid = 1;

To execute this query it will be necessary to login to the database. This is typically done through the command line or through a GUI interface such as phpMyAdmin.

Other possibility..

willvincent commented 4 June 2013 at 18:58

This issue was stumping me for an hour or so today. Turned out the cookie domain was being defined in the settings.php file, so while login authenticated successfully, cookies being set were set for the wrong domain so access would always be denied.

I was certainly scratching my head for a while there as to why password resetting wasn't working either via the UI or with drush.

Follow me on twitter.

Thanks Will!!!

fyberoptik commented 15 July 2014 at 14:59

Thanks Will!!!
I had this variable as part of the domain access module.

Reset cookie to match my local dev addresses, now working fine.

HELP

metzsmaksit commented 5 June 2013 at 16:33

I was having the same problem so stupidly I went into my phpmyAdmin and tried to make a new user with the same privelages, and after that didn't work i clicked "no password" and now when i go to the page to log in i find a message saying

"PDOException: SQLSTATE[28000] [1045] Access denied for user 'Drupal New'@'localhost' (using password: YES) in db_table_exists() (line 2761 of /Applications/MAMP/htdocs/Drupal New/includes/database/database.inc)."

What do I do??? Please someone help me.

I am having trouble

The Hawk commented 25 June 2013 at 15:31

I have changed the default front page via dashboard -> Configuration -> System -> Site information
and now i can no longer access the login page.
At first, the default front page field contained mysite/node. This works fine and is what i need, but i changed it to mysite/user/login. The reason for this change was because no matter if a person is logged in or out www.mysite.com does not redirect them to the login page. So, being new to drupal, I decided if I set the default front page to mysite/user/login then they would be forced to see the login page.
The problem I am now facing is that i cannot log in to the site to make any changes.

I have tried several different url paths such as:
mysite/user
mysite/user/login
I have also tried the unclean url versions. If i try mysite/admin I get an access denied message.

So my question is, where is the change i made stored in drupal 7's database? I would like to just edit the field that stores this change back to what it was to "unbreak" the site.

Front Page variable

sushantpaste

Marathi

Sawantwadi India

commented 2 July 2013 at 06:17

Value of "site_frontpage" is stored in the VARIABLE table .

Hth
S

I was having this trouble

le dendrite commented 20 August 2013 at 19:20

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.

*** Another Update ***
Issue still exists in Safari, only Safari... Any Ideas?

Problem Solved

brijesh.yadav310 commented 17 June 2015 at 06:37

Thanks le taco for this solutions great its working.

One way to quickly reset your

geerlingguy commented 6 August 2013 at 18:16

One way to quickly reset your password if you have drush is to run the following command:

drush @site-alias ev "require_once DRUPAL_ROOT . '/includes/password.inc'; print user_hash_password('newpassword') . \"\r\n\";"

(Where @site-alias is a drush site alias, and newpassword is the new password you want to use).

Then take the output that you get, and insert it as the new 'pass' value for your user account (in this case, user 1) in the users table. You can do this via drush as well:

drush @site-alias sqlq "UPDATE users SET pass = outputfromearlier WHERE uid = 1;"

(Where outputfromearlier is the output of the earlier drush command).

__________________
Personal site: www.jeffgeerling.com

...and even easier - see:

geerlingguy commented 8 August 2013 at 14:33

...and even easier - see: Recovering the administrator password.

If you have drush, you can just do drush uli, copy the one-time login link drush gives you, and paste it in your browser.

__________________
Personal site: www.jeffgeerling.com

with this issue

le dendrite commented 20 August 2013 at 18:29

you receive access denied after login, regardless of login method. At least I do.
Still having some trouble, actually. idk wtf is going on, but it's not much fun.

I had a similar trouble.

inri13666 commented 5 September 2013 at 07:28

I had a similar trouble.
The trouble was in call "drupal_settings_initialize" in a template file :)
P/S do not call this function manualy !!!

Check PHP version

mariocantor commented 30 June 2014 at 16:47

Well, I had the same issue, and after a couple days trying to fix it... finally I found that the problem is not cache , cookies or domain_cookie.... the problem i found in my case is the PHP version at the hosting. please be sure the version is 5.3 not 5.4///
so is really annoying issue, simple to fix it... but not easy to find it... all the post about it, did not mention something about PHP version... so hopefully this solve your problem..

=-=

VM commented 30 June 2014 at 17:03

I don't believe the issue is caused by all versions of PHP 5.4. I use PHP 5.4.29 and don't experience the login issue. It may be better to focus on the release of 5.4

PHP version 5.6.3 broken on OSX Mavericks

ecj commented 26 October 2014 at 16:21

On local server, OSX Mavericks with PHP 5.6.3-dev I had 2 problems & solved:

1. 127.0.0.1 (localhost) not resolving (httpd problem) -> unset the firewall/stealth settings -> OK now

2. Chrome browser couldn't log in to admin, but Safari could -> changed php to the std libexec php version -> OK now for Safari & Chrome

Hope to save others precious time by signalling those bugs.

yep that was sure frustrating

henns20 commented 29 October 2014 at 10:20

thanks - you got me in right direction.
#2 is what I was dealing with. Was not completely sure completely what you meant or where you did it by 'changed php to the std libexec php version ' - Changing the preferences on MAMP to the PHP 5.6.2 to 5.5.18 did the trick. Chrome allowed me to log on. Thanks for that note.

php 5.6.2 from entropy.ch breaks Drupal login

nicrodgers

English

Monmouthshire, UK

commented 7 November 2014 at 16:06

...I came to the same conclusion, this build of PHP breaks Drupal. Switching to the version included with Yosemite fixes it.

5.6.2 from php-osx.liip.ch as well

saltednut

she/her

English

Chicago

commented 8 January 2015 at 00:04

I had the same issue. UI-based installations were failing and I was unable to login via the webform. Drush based logins were working fine.

I rolled php back from 5.6.2 to 5.5.20 and I am no longer experiencing the issue.

To get it working for me was

_gramur commented 13 November 2014 at 05:43

To get it working for me was clear the sessions in Chrome.

Using Chrome:
1. Right click and Inspect Element.
2. Click the "Resources" tab
3a. Locate "cookies"
3b. Expand cookies tab
3c. Click on your Site (it should be your site URL or server name if you are on a local server)
4. Locate the cookie sessions. Usually the cookie sessions will start with "SESS". If you do not see this in your cookies you might have to truncate your session table in your site's database:
truncate table sessions;
5. Right click the SESS cookie and select delete
6. Log back in.

I briefly wrote about me experience here

_
Founder
Sivius.ca

Clear the cookies!

featherbelly

London, UK

commented 27 November 2014 at 23:48

Before you do anything complicated - just clear the cookies for the website!

Something like this makes it easy:

http://www.editthiscookie.com/

setting temp path

roopeshnaik commented 16 January 2015 at 07:39

strangely this resolved for me by setting temp path - drush vset file_temporary_path 'someexistingpath'

This worked for me! It is the

screon commented 19 March 2015 at 08:20

This worked for me! It is the first time I encountered this problem ever, setting the correct temp path did the trick.

Thx

knalstaaf commented 22 June 2016 at 08:17

Thanks, these steps helped indeed.

WHat worked for me

pawel.traczynski commented 23 January 2015 at 17:37

Within 60 drupal sites that we did, for just one of them we had to officially set $cookie_domain in settings.php.

For other 59 sites, this setting wasnt necessary unless we wanted to share cookies across domain and subdomains.

So if you have problems logging in, you can try setting your $cookie_domain.

The problem occured for us at Rackspace Cloud Sites hosting.

I am a Drupal developer and astrophotographer.
https://www.astrobin.com/users/pawel.traczynski/

Ucomment line in settings.php

athakural commented 9 March 2015 at 05:32

I faced the same issue in my fresh install of drupal7 on localhost. What I did is just un-commented the line
#$cookie_domain = '.example.com';
to
$cookie_domain = 'localhost';

It solved this issue.

i have the same problem

houmem commented 10 April 2015 at 08:58

i have the same problem, ich changed the chmod of the update.php file to 777 and that worked fine

Same problem but site was

markbannister commented 3 November 2015 at 22:14

Same problem but site was supposed to be connecting https but only connected http. Session cookie was set to ssl only.

I have face same problem on

vjsutar commented 19 February 2016 at 05:44

I have face same problem on chrome, I have clear all the cache of browser from beginning and problem is solved.

Just config apache mod_rewrite

tienbienit1992 commented 25 April 2016 at 10:04

I just run "sudo a2enmod rewrite". It work for me.

drush uli

knalstaaf commented 13 October 2016 at 08:37

You may want to try the drush uli command.

I had the same

sam-elayyoub commented 17 March 2017 at 23:38

I had the same issue and i solve it by:
1- Base url if it's on your local env "can solve the issue of login access denied + ajax issues"
2- Drush cc all (would show you if there is a problem with a module especially with your rebuild registry) "mine was the feature module trying to rebuild old feature"
**- Try to take off the $cookies_domain on your local env because it's holding your right results to show up and keep showing what's wrong instead

hope this help because it helped me to solve mine

Drupal 7 Access Denied user/1 after correct login

Comments

New forum topics