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
Tried removing Persistent
Tried removing Persistent Login as well, no resolution.
Have also verified its not a
Have also verified its not a cacheing related issue.
Have also verified its not a
Have also verified its not a cacheing related issue.
It appears the login link is
It appears the login link is not actively logging the user in.
Still ongoing.
Still ongoing.
User configuration at fault
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.
Have deleted all login/user
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.
Same problem here!! Disabled
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.
I've found the solution!!!
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...
Password Recovery One-Time Login Link "Access Denied" Error For
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
thanks!
Worked like a charm.
Worked!
Thanks a lot! I never had this problem before. Only happened after an upgrade from 6.16 to 6.22.
I did not have cookie domain
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
Install the firefox extension "web developer tool bar"
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!
Why would a cookie on my
Why would a cookie on my machine cause it to not work for every user?
So now I have tried with all
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.
Same issue with D6.17 even for user1
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?
It's a 6.17 issue
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.).
Same problem: Access denied on recovery password link
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.
Looks like Firefox is guilty:
Looks like Firefox is guilty: http://drupal.org/node/693516#comment-4515262