Okay, this is weird. Suddenly I can't login to ANY of my Drupal sites, from any computer or any browser!
I've tried clearing the cookies, and that does not change anything.
Symptoms - Enter Correct Login:
1. Login with correct username and password (on /user login form).
2. Get directed to /user/1
3. Message on /user/1/ says Access denied: You are not authorized to access this page.
4. Site does not recognize you as logged in.
Symptoms - Enter Incorrect Login:
1. Login with incorrect username and password (on /user login form).
2. Get message stating: Sorry, unrecognized username or password.
So, it is apparently it can tell the difference between the correct login and an incorrect one, but the correct login does not take.
I have tried deleting cookies. I have tried different computers with different operating systems. All give the same error. And the really weird thing is that I made no changes whatsoever to these sites in the mean-time. One week they worked, the next week they did not. And it happened to all my Drupal sites at the same time! I have several sites I need to update that I cannot login to anymore.
All are various versions of 5.x.
Any ideas on what happened and how to fix this issue?
Thanks.
Comments
Pardon the Typos
I apologize for the typos above. I don't see a way to edit my post.
System Information - Drupal 5.1 and 5.3
I tried many of the solutions suggested in other threads, but most seemed to apply to 4.7, not 5.1.
Here is information on the server:
Drupal 5.1 and 5.3
Apache version 1.3.34 (Unix)
PHP version 4.4.1
MySQL version 4.1.22-standard
Architecture i686
Operating system Linux
Have tried to login using the following:
Windows XP IE
Windows XP Firefox
Windows XP Safari
Windows Vista IE
Windows Vista Firefox
Knoppix (Linux) Konqueror
A customer is calling for me to change something on their site, and I can't login!!
I can login to drupal.org just fine, just cannot login to any of my Drupal 5.1 and 5.3 installations.
--
Scott M. Stolz
http://www.wistex.com/
First thing, I would update
First thing, I would update all sites to Drupal 5.7, for bug fixes etc. But I guess you have your reasons, so moving on.
Empty all database tables with the word 'cache' in their names. Also it doesn't hurt to run update.php even if there is nothing to update (it does some house-cleaning which sometimes acts as a miracle cure).
If that doesn't work either, then go to the settings.php file and set a cookie_domain for the site.
- In Drupal 5.3 this is done by setting
$cookie_domain='example.com'; (without www)- In Drupal 5.1 this is done by adding an
ini_set('session.cookie_domain', '.example.com');somewhere near the end (in this case notice the dot in '.example.com')If nothing works, then you will need to find out what changed...
Thanks for the
Thanks for the suggestions.
I've tried deleting the cache records and that did not change anything.
I do not see update.php anywhere in the file structure. Perhaps I missed it.
Changing the cookie setting in settings.php did not help.
My next step is to upgrade to 5.7 or 6.2 (depending on availability of the necessary templates) to try to solve the problem.
I'll keep you posted.
--
Scott M. Stolz
http://www.wistex.com/
=-=
update.php should be in your root drupal install. same place index.php is.
if you don't have one that would begin to make me question the integrity of your installation and whether you installed Drupal yourself (best way) or used a one click script like fantastico from your host. If the latter, you will be pretty much on your own.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
update.php should be in
update.php should be in Drupal's installation directory, but if you upgrade you will get the new one anyway.
An upgrade to 5.7 is normally just a few minutes. Upgrade to 6.2 is another story... you will need to replace all the modules (if they have new versions) and the theme.
Good point.
Good point. I should upgrade to 5,7 first to see if it solves the problem. I might try 6.2 on sites that have no modules installed.
And update.php is missing for some strange reason. Most of these are Fantastico installs, so maybe that is why. They worked fine for 6 months, so not sure what happened yet.
--
Scott M. Stolz
http://www.wistex.com/
Upgrading a Nightmare
Upgrading is a nightmare since I can't login as Admin and disable the modules beforehand.
--
Scott M. Stolz
http://www.wistex.com/
=-=
modules need not be disabled in an update of a 5.x - 5.7 installation.
upgrading to 6.2 you would have to go into the DB manually specifically the system table and set all modules to 0, though I don't suggest this large a step as the modules you are using may not even be available for Drupal 6.2.
my suggestion is to stay focused on Drupal 5.x and get your site working properly again.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Additionally, to make things
Additionally, to make things simpler during the upgrade, you may want to disable clean-urls temporarily: Edit your settings.php file and add at the end the line
$conf['clean_url']=0;(Normally this is not needed but might help in your case.)If you can't login, which is required for running update.php, you can edit a line in it according to the instructions it contains in the comments. Don't forget to undo this afterwards, because it is a security hazard.
Emergency Workaround
For those of you who cannot login, but need to change pages immediately, don't forget that you can edit pages in the database directly, which is what I wound up doing just now.
You can find the nodes in table node_revisions. If you MUST change the pages, only change the title, body or teaser fields, and don't touch anything else, unless you know what you are doing.
Be very careful, as any changes you make could corrupt Drupal. But changing the title, body and teaser of a node should not corrupt the Drupal database.
If you do not know how to access a database, then I would suggest not trying this.
--
Scott M. Stolz
http://www.wistex.com/
Why would path be set to /tmp?
Looking at the cookies and comparing sites I can login to with sites I cannot login to, it appears that all the sites I can't login to have the path set to "/tmp" while the ones I can login to have the path set to "/".
I am not sure how that got changed or where. How do I change the cookie path back to "/"?
--
Scott M. Stolz
http://www.wistex.com/
First: Before doing any
First: Before doing any upgrades make a backup of your databases. I cannot stress this enough.
This is standard o.p. but some people keep forgetting this. It will turn a complicated situation into a nightmare if you're not careful.
I'll post later on this.
Edit:
Are these live sites or development? If they are live, download the sites and work on them locally.
Edit2:
Now:
Do you use ?q=user or /user as login?
If the first then it is my experience that it has to do with the clean url's. If the second then your clean url's would appear to me to be o.k. and the problem could be somewhere else. (I don't think it is, but I am not ruling it out).
I have had this 'error' before popping out of nowhere. And I don't remember how to fix it. It was something really simple. As soon as I remember it I'll post it. Good luck in the meantime. Hopefully somebody will have the answer for you in the meantime.
Response
Yes, we have backups of both the database and the files. I tried upgrading one of the sites, and the upgrade did not work, so we rolled it back. Upgrading without disabling modules causes problems, and we can't login to disable the modules.
These are lives sites. They were all working, and suddenly we can't login to any of them. The cookie path is now set to /tmp somehow and we have no clue how it got that way or how to change it back to /.
And all of them use clean urls (i.e. /user).
It probably is something very simple. Just figuring out what that simple thing is can become complicated. :)
Any help is appreciated.
--
Scott M. Stolz
http://www.wistex.com/
Strange. Are the '/tmp'
Strange. Are the '/tmp' cookie paths created again if you delete those cookies?
Normally the cookie path is derived from the $base_url.
If $base_url = 'http://example.com'; then cookie path should become '/'.
If $base_url = 'http://example.com/site'; then cookie path should become '/site'.
You could also set it directly in settings.php, using ini_set('session.cookie_path', '/'); but that shouldn't be necessary.
Problem Solved (Actually a Workaround)
Yes, all new cookies have /tmp instead of /. Deleting a cookie just results in a new cookie set with path /tmp.
The base URL is set to the domain name correctly. I am thinking that the web host changed something and it screwed up the cookie path, because every Drupal installation on the server does the same thing. I put in a ticket with the web host to see what is going on.
Looking at the PHP settings in Cpanel, it appears that main session.save_path is set to /tmp. I am not sure if that is what did it, but I can't change it to find out since it is a shared hosting environment. I don't know what it was before, so that may not even be it.
I tried the ini_set('session.cookie_path', '/'); in settings.php and that solved the problem. It overrides what the PHP on the server is doing.
Thanks for your help. I really appreciate it.
If the web host responds back, I'll give you guys an update on what happened.
--
Scott M. Stolz
http://www.wistex.com/
Yeah I was thinking the same
Yeah I was thinking the same thing. Contacting the webhost in any case is a good idea if this is happening to multiple installations on the same server.
The thing I was talking about was actually the cookies being turned off in the browser. But as you are trying different browsers on different computers this would be unlikely unless you had the same settings everywhere.
Hope it works out for you. :-)
Web Host Fixed It
The web host fixed the issue, but they did not tell me what they changed. So it appears that it was something the web host did.
It should be noted that ini_set('session.cookie_path', '/'); in settings.php also fixed the issue. But whatever the web host did, made it work without adding that statement to settings.php. (I have multiple installations on that server, so I gave them a site without the aforementioned modification to play with to get it working again.)
Thanks for the assistance.
--
Scott M. Stolz
http://www.wistex.com/
Hi! Where are you hosting
Hi!
Where are you hosting your sites? I had the same problem, and, while researching on how to fix it, it got back working again, so I guess it was something done by the webhosting. My site is hosted ad cirtexhosting.
Regards,
Carlos.