Is there a problem with this plugin?? Did the Spammers find a way around??? I have been getting many registrations the last few days from spammers, and most of them are listed on the Stop Forum Spam site, but are still being allowed to register????

John

There was some downtime on the sfs site which meant that if you had the mod set to allow registrations if the ip/name/email check timed out they'd get through.

Had a couple of nasties myself

Where is the vBSFS cache stored by the way, in the vB SQL db or a separate file somewhere?

vbstopforumspam_remotecache table in mysq

Ive got a small bug fix due for release shortly, that touches on the caching

the problem continues, dropped you PM with the IP of the server.

Try downloading the patches from this site again, Then obviously, you'll want to unzip them and then upload them to your server again. Certainly sounds to me like something got glitched somewhere.

I'm only running vb 3.8.1 on the site where I'm using this addon; but I'm not seeing any issues of the type you describe at all.

I'd say roll back and start over from the very beginning (including the download and the extract from the ZIP file) and see if that doesn't solve it. Also please note this comment from the install instructions:

If you cant see the logs in ACP/ Statistics and Logs, then you didnt upload the contents of the "upload" folder.... Its there for a reason, upload its contents to the root of your forum. This isnt an issue, its just something that 99% of the "it doesnt work" issues arise from

I doubt that it applies in your case; but it's certainly worth checking.

Good luck. Hope this helps!

Floris is all fixed so just ascender to go.

Let me try to explain it from how I've looked over the code.

The main need for the local cache is because of where the hook location is in the registration code. Pretend a person (or bot) messes up their registration and the system throws an error (say they messed up the CAPTCHA, or forgot to fill out a required field). The hook to check SFS occurs after every "submit" is hit on the registration page, but before vB error checking and final user saving is done. Thus if a bot is pounding the registration with failed attempts it would in turn be pounding SFS with the same query over and over again. The local cache alleviates this problem since the Username/Email/IP should be the same through several attempts to get a successful registration.

I think it would be okay to cache the definite hits for the long-term, but usually after failing in that one short time-span, you won't see the same user/email/ip combo again. (especially if you already banned the user, which would also prevent the same email address from being used). And if it's a dynamic IP, eventually a legitimate user *could* get blocked because you cached results for several weeks (or are not checking how recent the last bot was seen).

But anyhow, I think having a short local cache is more than sufficient. I've seen bots pound the registration with failed attempts, but still the local cache is not allways effective since they sometimes will try different usernames/emails/IPs when the previous attempt is not successful. Fortunately for me there's tell-tale signs of being a bot (i.e. 10 registration attempts in one second) which gets them submitted to SFS. Also I have other checking that I do before querying SFS to tell if they are a bot, that helps Pedigree out in reducing load on his server.

Thanks, eco_Jason. This explanation was very helpful even though it doesn't quite fit the bot behaviors I've observed. One thing I have realized over the past 3 years is that if one works out a strategy that is highly effective in defeating these borg-beasts they soon begin to deliberately study you to figure out how you're defeating them and try to devise a strategy to work around your protection technique. For example, the appeal of one of my sites is primarily U.S.-Regional So 2 years ago I decided I could block 99.999% of bots just by blocking and/or removing all registrations from anywhere in the world outside the 7 major U.S. and Canadian time zones. This was virtually 100% effective for months. In fact it was so effective I eventually set the underlying mysql query up as a cron-ed script and ran it every 15 minutes 24 hours a day 7 days a week. Presto. NO more bots! It worked perfectly for months.

Then one day I noticed I had a new registered user whose name was "FigureOutTimeMachine" (I'm not kidding you. So help me God, that WAS it's name!). Then within a few days my "time zone defense shield" suddenly didn't work anymore because the bot authors had rewritten their code and were now deliberately lying to my server about what time zone they came from.

Frankly, I suspect we may be seeing different attack patterns and strategies because the bot-authors are using their tools to study how our defenses work in deliberate targeted efforts to figure out how to defeat them. If THAT doesn't increase your paranoia level, it sure should! It says our enemies are studying us and getting smarter about how to defeat our best defenses every day... :eek:

Thanks again for the explanation, Jason. I'm not afraid to say that even after 42 years in the IT field, I'm still learning. Anyone who doesn't believe we're fighting the skirmishes of the world's first cyber war should come spend a few months on the front lines with us. They'd learn they're wrong real fast.

Just in the past few days I've had people contact me that are trying to register and they are not spammers.

I'm going to have to disable this and find something out it seems.