After ONE edit, member FORCED to log out ???

Here's another weird one. I'm having severe session timeout problems when a member edits a blog. The first time that blog post is edited there's no problem at all. But if a mistake was detected by the member during a re-read and the member wants to edit the post again from within their profile/blogs section, then the edited post just times out time and time again, with an error such as this one:

Fatal error: Maximum execution time of 180 seconds exceeded in /var/www/virtual/d7domain/htdocs/plugins/phpids/IDS/Monitor.php on line 498

This used to happen before and then I saw a post where someone increased the execution time, which I did. However, now I'm thinking that this has nothing to do with it because the first edit after logging in new always works without a problem in a matter of a few seconds. We have a dedicated Debian 64bit server with 12 GB ram and quad core processors. One working installation of D7 is really the only thing that's being utilized, aside from a hand full of domains which are mostly empty with very little activity. So I don't think that max execution time has anything to do with the server itself ... ??? Any ideas, thoughts, or solutions would be highly appreciated since I can't offer D7 to the public like this?

EDIT: Okay, I just logged in as admin from another browser after the member had been logged off. Then I tried to edit the blog post from within the admin settings ... and STILL received the same error as described above. This is just not acceptable for a community platform. Any ideas at all?

Quote · 13 Apr 2010

BUMP ... next day ... member was logged off overnight ... yet the problem is still evident. Same error!
An edited blog post by the posts owner cannot be submitted due to this error.

Here's the only solution that I could find ....

Since we've been able to monitor this problem with the blog post editing for several days, we figured that some of the security attack message that we've been receiving may have had something to do with this as well. No matter what we set those security level settings to (admin/advanced settings/other), eventually we'd still receive more errors and more security attack messages with an ever increasing total impact level. From the original 25 to 28, then 31, eventually ending up at 38 today.

Feeling as though we had no choice, we set both of the threshold levels to -1 thereby disabling the PHPids function completely. This should be alright to do if your server has firewalls and other security measures in place. Well, as soon as we did that, we haven't had any more security errors or blog post editing issues.

Quote · 14 Apr 2010
 
 
Below is the legacy version of the Boonex site, maintained for Dolphin.Pro 7.x support.
The new Dolphin solution is powered by UNA Community Management System.