Could someone help shed some light on an issue I am having with a site? The contact page keeps getting stuck and displaying the message "you cannot send more than 2 messages per hour", yet I have never sent a message from the form. It shows up on different computers and appears to be displaying the message for anyone who tries to "contact" the site using the standard contact form. I can go in and flush the cashes, and it clears the message and displays the contact form.
Could this be related to the cache life being set to six hours on the performance page? I am not sure if I have given enough info, if more is needed I will try to acquire the needed info and re-post.
Could this be from people trying to hack the site? There are all kinds of entries in the /admin/reports/dblog of anonymous users trying to access pages that do not exist (e.g. node/229), trying to access css and js files, and things like this - _sql/scripts/setup.php.
Comments
This is limited by IP not user
Assuming you are using 6.x, I did a search for your message in the code and found that it is triggered by the flood_is_allowed function in the common.inc core file.
The limit is based on what is stored in the "flood" table and the contact hourly threshold setting. The flood table keeps event, hostname (IP Address), and timestamp info for a lot of things. For contact usage, the event type is "contact".
So, it's not based on user access but times an IP has been used. This leads me to wonder if your site is behind some sort of load balancing proxy server which makes all request look like they are from the same IP address. If so, then maybe your site "probers" are triggering the flood blockage.
First step to telling this would be to see what the "contact" entries look like in the flood table. I.e., run the query below in your SQL manager software and see is the hostname values are the same:
Select * from flood where event = 'contact';
First step
Sorry about making anyone have to make assumptions, but you are correct 6.22. I opened my database with phpadmin, scrolled down to the flood table. There were six entries and only six. All of which had "contact" as the event. Two of them had the same hostname address. According to this site http://www.ip-adress.com/whois/ the address is located in India. None of the addresses are my service provider or my computers. I ran the query you suggested from the main database and got the same answer.
I have the contact form set at 2 per hour at admin/build/contact/settings. I will check to see if it is behind "some sort of load balancing proxy server". What is "'fid"? Is it functions id?
I searched the database for the repeating hostname above, and found five entries in the captcha_sessions table, two in the flood table and two in watchdog table.
Is any of this info helpful?
That seems OK
Since you have individual IPs in the table, it seems like your hosting company isn't doing anything that's hurting this.. but it was worth testing. (FYI - fid = flood id... just an incremental record id for the flood table).
Not sure where to go next, the contact form code seems pretty simple, the URL /contact calls the contact_site_page function. This does a check to see if the IP has submitted more than the limit. Then
displays either the message or form.
The flood check is is just a simple select a count query against the info in the flood table.
Your limit seems to be stored correctly since it's displaying as "2" in the message. So it hasn't been corrupted to be "0".
There are no "hooks" called that would allow other modules to interfere. Unless you have a module that replaces the /contact URL for some reason.
Some possibilities might be:
Your contact module code has been modified/corrupted... copy the modules/contact directory from the live site and compare to the 6.22 core zip contents.
There is a problem with the SQL query for some reason (MySQL / PostGres / version differences issues). Long shot since the query is pretty standard.. but it does deal with timestamps and the format of these have changed between some versions of SQL Servers as they try to become meet current SQL standards.
You might check your PhP error log to see if there are any problem noted there.
That's all I can think of..
possibilities
I compared the directory and each file in the core with the directory and files on the site. They all matched.
As to the query, it was searching for any records with "contact" as event in the flood table, and the flood table itself only had contact events and only the six that the query produced. Had there been other events the query would have weeded them out. Since there were no other events in the table, then it seams it did work correctly.
There may be something in the php error logs. It will take a while to go through them. However, this site was set up years ago and has all the old site folders and files still in the /public_html/ where the Drupal install is also. All the php errors are from files in folders from the old site. None of the errors show them from the Drupal folder. I noticed that some of the "page not found" errors at admin/reports/dblog have been referred by pages on the old site. I guess I should get rid of all the old site's folders and files.
Is there a way of extracting the dblog? I looked into some modules and have tried to create a view, but have not had success with this yet. I have been going through dblog line by line and copying out the information stored. It is a slow process.