Users are able to log in and change their own passwords successfully, and when a password is requested to be reset the email and one-time login link arrive correctly. However, once a user has clicked the log-in button (on the one-time login page) they are redirected to the login page where it says Access Denied.

In the logs there are no problems, it only shows the session opening for the username and (weirdly) a timezone change for the user.

This occurs on Firefox, Chrome, and Safari and on (from what I've tested) all user accounts. I've disabled all login/password/user modules (not using many, using some Rules for logging in redirection that I tried deleteing and the Change Password Module) but no solution.

Thanks!

Comments

egsj’s picture

Tried removing Persistent Login as well, no resolution.

egsj’s picture

Have also verified its not a cacheing related issue.

egsj’s picture

Have also verified its not a cacheing related issue.

egsj’s picture

It appears the login link is not actively logging the user in.

egsj’s picture

Still ongoing.

danbryant’s picture

I was having a similar problem. Turned out that it was the way that the user account sign-up process was configured: example.com/admin/user/settings ; set to "Visitors can create accounts but administrator approval is required."

New users could not reset their passwords until an admin had authorized the account sign-up.

Instead of "access denied" a better message would be: "User account has not been authorized for login yet".

A simple message, telling the user what was really wrong, can save a lot of jiggery-pokery.

egsj’s picture

Have deleted all login/user modules, deleted all rules, turned off all caching and performance modules and both behaviors are still persisting - new users are not automatically logged in and the password reset one-time login button (the link in the email does work) leads to an access denied page.

felipe’s picture

Same problem here!!

Disabled rules (it was redirecting user to another page), also remember_me module and cleared all caches. After user clicks on the link sent to his email and pressing the one time Login button: Access denied on page /user/%/edit.

Don't know what to do anymore.

felipe’s picture

I've found the solution!!! Disabling the $cookie_domain setting in settings.php allowed users to recover lost passwords.

This is odd since $cookie_domain was correctly set to the site's url. Anyway...

doubtintom’s picture

So at least I'm functional again, but what happened? Probably the last thing that I did to that site was to upgrade to 6.17 and also upgrade a bunch of addon modules. Is commenting out the cookie_domain going to create a bad side-effect?

Does anyone know the root cause or have tips on where to troubleshoot?

Tom

danbryant’s picture

Worked like a charm.

radj’s picture

Thanks a lot! I never had this problem before. Only happened after an upgrade from 6.16 to 6.22.

egsj’s picture

I did not have cookie domain enabled in settings. However, I tried enabling it and the problem persist. At the advice of IRC I have captured the headers being sent after login from Firebug. I have tried disabling all contrib modules with no effect. I also updated every contrib module again with no effect.

"Date Wed, 16 Jun 2010 21:46:06 GMT
Server Apache/2.2.3 (Red Hat)
X-Powered-By PHP/5.2.13
Expires Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified Wed, 16 Jun 2010 21:46:06 GMT
Cache-Control store, no-cache, must-revalidate, post-check=0, pre-check=0
Set-Cookie SESSdb7345d32ca0e47118fce7e9579b0e68=deleted; expires=Tue, 16-Jun-2009 21:46:05 GMT; path=/ SESSdb7345d32ca0e47118fce7e9579b0e68=kuar2oegsq1r0i4lt5f1ntfc31; expires=Sat, 10-Jul-2010 01:19:26 GMT; domain=.domain.com
Location http://www.domain.com/dashboard
Vary Accept-Encoding
Content-Encoding gzip
Content-Length 20
Connection close
Content-Type text/html; charset=utf-8
Request Headersview source
Host www.domain.com
User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 FirePHP/0.4
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Referer http://www.domain.com/user/reset/49/1276724745/e5bc90ac967ad3f163ae5e8b4...
Cookie SESSdb7345d32ca0e47118fce7e9579b0e68=jo4ujcb3tbbt1fuu6l8sik4hd1; has_js=1; __utma=100784147.1807036565.1276724725.1276724725.1276724725.1; __utmb=100784147.8.10.1276724725; __utmc=100784147; __utmz=100784147.1276724725.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); _jsuid=1464427777144534964"

"Date Wed, 16 Jun 2010 21:46:06 GMT
Server Apache/2.2.3 (Red Hat)
X-Powered-By PHP/5.2.13
Expires Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified Wed, 16 Jun 2010 21:46:06 GMT
Cache-Control store, no-cache, must-revalidate, post-check=0, pre-check=0
Vary Accept-Encoding
Content-Encoding gzip
Content-Length 4209
Connection close
Content-Type text/html; charset=utf-8
Request Headersview source
Host www.domain.com
User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 FirePHP/0.4
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Referer http://www.domain.com/user/reset/49/1276724745/e5bc90ac967ad3f163ae5e8b4...
Cookie SESSdb7345d32ca0e47118fce7e9579b0e68=jo4ujcb3tbbt1fuu6l8sik4hd1; has_js=1; __utma=100784147.1807036565.1276724725.1276724725.1276724725.1; __utmb=100784147.8.10.1276724725; __utmc=100784147; __utmz=100784147.1276724725.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); _jsuid=1464427777144534964"

"Host www.domain.com
User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 FirePHP/0.4
Accept */*
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
X-Requested-With XMLHttpRequest
Referer http://www.domain.com/dashboard
Cookie SESSdb7345d32ca0e47118fce7e9579b0e68=jo4ujcb3tbbt1fuu6l8sik4hd1; has_js=1; __utma=100784147.1807036565.1276724725.1276724725.1276724725.1; __utmb=100784147.10.10.1276724725; __utmc=100784147; __utmz=100784147.1276724725.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); _jsuid=1464427777144534964
If-Modified-Since Wed, 16 Jun 2010 21:45:26 GMT"

i have also checked the cookies and am getting: hs_js, SESSlongrandomstring 7 of these), cluid, cslhvisitor, cookieid, and _jsuid

kewlguy’s picture

I would suggest that the first thing to do in this situation is to install the firefox extension "web developer tool bar" and then surf to the main page of your site.

While on the home page of your site choose the second button in on the developer tool bar titled "cookies" and then choose to remove the session cookies now you likely will be able to use the recover password feature again.

Good luck!

egsj’s picture

Why would a cookie on my machine cause it to not work for every user?

egsj’s picture

So now I have tried with all relevant modules removed from the server and the database. I did a fresh Drupal install on the same server and had no problem with the password reset functionality.

This is in conjunction with several other errors - for instance, often when a user logs in, the page refreshes and they are not logged in - but no error occurs either. On second attempt they generally can log in without error.

Also, if a user logs off one account, then on to another, a page refresh will show them on the original account, and another switches them back to the new account.

lameei’s picture

I got the same issue. First couldn't log in with user1, i thought that I'm wrong with password so i tried the reset password, by clicking on the link inside the email i got the access denied page. after commenting out the $cookie_domain in settings.php now i can log in with success. This should be a bug i think. isn't it?

Branjawn’s picture

Session handling

Drupal 6.17 changes the way session cookies are handled. Most people don't need to have this setting set, but if you have an explicit $cookie_domain set in settings.php, verify that it is set to a sensible value:

* 'example.com' if you want sessions to apply to the example.com domain, and none of its sub-domains (especially not www.example.com),
* 'www.example.com' if you want sessions to apply to the www.example.com domain, and none of its sub-domains nor parent domains (especially not example.com),
* '.example.com' if you want sessions to apply to the example.com domain and all its subdomains (www.example.com, mydomain.example.com, etc.).

EnekoAlonso’s picture

I have had the same problem for almost two years. Haven't found a solution yet.
http://drupal.org/node/877550#comment-4515144

Enabling/disabling the $cookie_domain setting on settings.php does not have any effect.

EnekoAlonso’s picture

Looks like Firefox is guilty: http://drupal.org/node/693516#comment-4515262