Skippy has it. There is no link in the logs as no user account was created.

Duplicate logs for each user isnt really a duplicate. If you have a "log but allow" policy or a user that is registering is beyond the cut off date allowed (ie listed on sfs.com website with a lastseen of X days ago, where X is bigger than the configuration in your forum), then it logs this and continues with registering / adding the user, where it logs a new user registration.

Successful registration is there as a request from people, so that they can click through to users even if they generated no warning, a "one stop" portal page if for no better description. I will add an option to disable that in the next version if you like

And these users exist? The registration check has two parts (as it uses two differnt vb hooks).

The first part does all the work, queries the server and logs if it finds a spammer, blocked or allowed.

The second part does one thing, it logs succesfully created users and attempts to join that user with its username logged in step 1 by the means on a unique token in the logs. If a new user is created and you can see it in the user options and there is no link in the logs to that user for a log entry, then there is a bug that I will have to address.

It should be that way, yes. but Im going to go back to the code and figure out if thats not the case all the time.

For those finding users registering, please verify their userid and if there is a link in the logs to the usercp for them. If you find a valid user and no link to the user cp, please PM me with the exact version of vBulletin and a copy/paste of the log entries.

I've been using this mod for a few days now, it's really doing a great job thus far. I'd highly suggest adding an option to allow the flagged registration to go through but have them go into a special usergroup we set up.

abrecher - Ill add that to v0.7,which is coming along nicely.

Its got GUI integration now (both in 3.7 and 3.6 in the same package), just need to add permission controls to that and recode the backend record / caching as Ive rewritten a lot of it to cut down on the number of remote calls and to allow for further changes if and when theyre made. Youll be able to submit details to the remote website from the GUI, once I get a response from the guy who runs stopforumspam.com

Ive just looked at the source for 3.7, specifically this

// assign user to usergroup 3 if email needs verification
if ($vbulletin->options['verifyemail'])
{
$newusergroupid = 3;
}
else if ($vbulletin->options['moderatenewmembers'] OR $vbulletin->GPC['coppauser'])
{
$newusergroupid = 4;
}
else
{
$newusergroupid = 2;
}

There is the ability to change the user group after this but we could run into a problem. The default "new user" group is 2 but as you see, if there is COPPA or VerifyEmail set, a new user goes into a different group. Moving a user out of VerifyEmail to another group, will (but Ill have to double check) bypass email verification testing. Still, I guess if youre moving new users into a group, theyre not going to have any posting ability as part of the permissions of the special group.

Ill add it, disabled by default, with an explaination of the ramifications of a different default group, blocking admin/mod/supermod groups in the code (because otherwise, that would be bad)

Thanks a lot for this mod!!! It's a great idea.

When will we able to add spammers to the stopforumspam from vbulletin?

Please read the post right before yours.

This plugin stops approximately 15-35 spammers from signing up to my forums DAILY! I'd HIGHLY recommend it to anybody with a busy forum. I'm using it without any issues on VB 3.7.1 . Thanks again to pedigree!!

Youre welcome and thanks for the feedback, its always nice to hear from people that appreciate the effort involved. If you think v0.6 is good, wait until v0.7 :)

The only real thing stopping it being included right now is that the guy who runs stopforumspam.com doesnt have an API system for submitting data yet. What I am doing in v0.7 is using cURL to submit data to his online HTML form. Its not ideal for a couple of reasons

- If he changes the form code, its values or does referring checking, it breaks all the template code. The results have to be parsed out of HTML code, rather than the current read API where the results are in a known XML format
- If you dont have cURL installed on your webserver, then you have to use a local form in your template, which exposes your API key to anyone you grant vbStopForumSpam access to. This would then allow them to use your key to create false records on the stopforumspam server (if they wanted to be malicious)

Its not me delaying the ability to submit data, its just waiting on the finalised API from russ (who seems to be a very very busy guy)

Thanks for explanations pedigree. If it's possible to add this feature in the future, this mod will be the most efficient weapon against spammers.

Keep up the good work.

Modification Request:

Perhaps a way to sort the columns of the log, as well as a way to show the top 10 blocked IPs / email addresses / user names?

Also, a way to graph some of the stats, and search within a time frame? I'm guessing there's functions already built in that do these, based upon the standard vB logs.

Wired, way ahead of you there, well, a bit.

I was thinking about the table structure for graphing the statistics just last night. I did this for an intranet helpdesk system at work and the management loved the graphing more than the 8 months actual work, typical :)

I hope to have both a html table and a GD bar graph. Im also going to add support for GeoIP to report by country and much better sorting in the logs system. Ill certainly add a date search timeframe to the logs as well.

Ill sneak in an option to PM users each day with a breakdown on the blocked/logs registrations as well.

Support for GeoIP to ban based on Geological Data would be great, too.

One stop solution against Spammers :)

That can be done as a comma delimited list of country codes

eg

cn,kr,br,ar,ru

Sounds great :)

Don't forget about proxies...

Most of our spammers either don't find a proxy (open ones are getting rare) or didn't use one.

installed / tested. awesome mod, exactly what i was looking for when searching for spam. kudos to you.

note: to all of those complaining, it is almost impossible to stop -every- spammer with one simple program/script. this just adds on to the help of ridding the annoyance.

I can put RBL lookups in there as well but I think there is already a mod for that.

The GeoIP has some anonymous proxies, which I can use to add additional tests. If someone has the GeoIP full version and would like to test the mod against that, then even better.

Maybe I could add functionality to check new posts against the surbl website RBL as well... maybe after v0.7

Thanks :) Now click Installed :cool:

@pedigree: I just checked, the last NN spammers weren't clever enough to use a proxy. Mayber they are even in countries where they cannot/must not use proxies...

Thank you Great Firewall of China.... Adding a check box to "Block anonymous proxies" isnt a huge code change with all of the code rewrites Im doing. Ill add it, you never know, it might get a spammer

My weekly praise to pedigree and the amazing work on this mod.

Just took a look at the last few days activity:

Out of 6740 attempted registrations:

• 1850 of them were valid users
• 100 were blocked due to email
• 3200 were blocked due to IP
• 1590 were blocked due to username

For what it is worth, I use a real time analytic tool GetClicky. One thing that I do when determining if a user was improperly rejected is to check the IP address and see if there is activity on my site. 100% of the time so far they do not show up, most likely indicating that they are blocking javascript from executing. I'm not sure if this is helpful information as a secondary check or not as it seems that it may catch users with outdated browsers as well, but so far is a good canary for me.

That gives me my own IP address instead of the users (in userinfo template), what's the correct var for the members ip addy?

I realize a lot of these suggestions are dependent on a better API / submission system from StopForumSpam.com :)

Suggestion: Once a submission function is built in, perhaps add an additional layer of analyzing to it? Example:

User1 / Email1 / IP1 was found to be a spammer via IP today. 3 hours later, they attempted to register again. User1 / Email1 / IP2.

So, if someone that's attempting to join passes, a last check would compare their user name and/or email and/or IP to previously blocked registrations. This way, they could be shut down from registering under slightly different credentials. An option in the adminCP could be added so the Admin can say how many days back in the log file to check (if not the whole thing).

Suggestion: If a submission is blocked, grab the rest of the offending info from the StopForumSpam site, and compare against the suggestion. If it doesn't all match, submit the submission's info so the StopForumSpam site is more complete.

Suggestion: Also, perhaps a function that would compare only allowed registrations to the StopForumSpam site. After all, some spammers make a login, and then don't spam for days. If another forum has caught them and flagged them, now you can be aware of this "sleeper" member and ban them. Notice could come via PM or New Thread post (akin to the Multiple Login AE mod here).

Not sure what would be best: checking on a CRON (or something similar), or only checking via a manual button. Perhaps an additional table column, so that if an allowed registration was checked 3 times after the account was created, it won't be checked again (so as to limit bandwidth and resources, both on the forum and StopForumSpam's site). Also, an option for the admin to manually OK an account, so it's bypassed in this check (or automatic, e.g. 20 posts in the forum, or in a certain group, or whatever).

Suggestion: A search for the log would be nice as well :)

Suggestion: Once the manual / auto submission tool (and possibly some of the others I've suggested) are in place, color code (or whatever) the log? Example: Spammers I've submitted in red, (easily customizable by admin via FFFFFF), or mark by symbols (searchable of course), ones thoroughly checked in green, etc.

The obvious risk is that users that were originally flagged incorrectly that you manually approved would get caught. If this kind of checking happened it would need to only affect users of a certain user group(s).

My vote would be to tie the "re-check" to an activity that would warrant concern (posting, PMing, etc)..

Scenario being a "Registered" group and a "Promoted Registered" group. Users in registered group are checked against StopForum before being allowed to post. Failures can either be quarantined or prevented.

Set up a promotion schedule (time, # posts, whatever) to move users to Registered so your trusted users don't pay performance penalties.

You're talking about the comparison down the road? It doesn't have to auto-ban them or anything, just notify the admin of this new information. They can decide depending on the user's posting habits, the frequency that they showed up on the list (that's already part of the API), a simple google check, etc.

StopforumSpam.com doesnt have the functionality to pull all the other details for spammers based on just one field. We cant get a list of IPs that SpammerX has logged in from. I can however, put all the details for a failed registration into the database. To be useful over a 24 hour period, I might think about changing the local cache from 90 minutes to 24 hours.


When I get all the template code working, there will be options for mods to examine users, refresh SFS.com data and act on that. In order to run proactive scanning against all the users against all SFS.com data, would require more work both on my time (I have a baby due in 6 weeks) and in cron execution time. Unless you have the Ajax cron mod installed, running a job like that would kill so poor users session. Maybe in v1+ Ill be able to add an automated pull from SFS.com of their IP lists. Anything more would be a lot more code. I want to get the next version out, working before baby is born because after that, well, I wont have much more time until I go back to work.

Ill add a search to the logs after I get all the new code working

Auto submit can be sorted and logs updated to reflect that, its not a big, as long as you have cURL installed. Without cURL, automated submission will be extremely difficult, something that can be done but something that Im not really wanting to code for.

main goals for the next couple of weeks, is to get the core rewrite sorted, the 2.6 and 3.7 template changes sorted so that they rewrite templates on the fly, allowing mods to view all the data about the user, do whois/google searches, updating SFS.com data and submitting them manually, better loggind support and statistics reporting. Auto submitting user data to SFS.com might sneak in there but any companion, posting, PM etc will have to wait until all that is stable.

I spend 4-5 hours a day on a train to/from work so my time is a bit limited but Im trying to get it all sorted and out asap.

Yeah, thats why I posted an update to v0.61 saying that you should remove the template changes. In the next version, all the templates changes will be automatically made. Ill have a couple of people who said they will help me in the testing, which will ensure I dont make some an awful screwup again :)

I think it might be $userinfo[host] but Im not on my machine, that could be wrong.

Thanks for the numbers, gives me a warm fuzzy knowing that I might be p*ssing off at least one spammer. Maybe he might get so depressed at not being able to register and will just kill himself, fingers crossed

vBulletin works without javascript and this would block everyone using NoScript in Firefox (like myself, I wouldnt be without it). Ill put it in the bugtracker as a "maybe feature" for a future release though, maybe with a notice in the new user that says "Javascript is required for this registration" where isubmit button disabled by default, javascript used to enable it and with javascript used to make a form value. That would give fair warning to users with javascript disabled etc (personally, I HATE websites that refuse to work with javascript off and prefer not to use them)

I hope you think about server load for Big Boards to only user the code where really needed ;)

Yup, certainly have. Currently (and I dont imagine its going to change much), it uses two hooks that are hit on each page, global_start and cache_templates.

global_start is used to test if the page is member.php and then inserts a menu item into the options_postbit, that is one or two conditional checks. Firstly, it checks if its running 3.6.x as 3.7.x doesnt have the options postbit menu (3.7 has user details page load as a profile block instead).

cache_templates is used to check if the page is showthread.php or misc.php and then tells vbulletin to insert the "left click username context menu" postbit or the new user detail templates into the cache. A lot of mods do this and it shouldnt impact performance at all.

Once in the cache, vbulletin and any accelerators, will take care of that. Template checks shouldnt be a hit at all, but thats the price to pay for auto template changes.

I dont have a large board to test it against but Im open to suggestions

Ok, thanks.

I can test it on our boards, you see the microtime in the footer.

You can from the search page. This one goes back to a better API being in place.


Congratulations :) This could be done manually for the time being, and wouldn't kill anyone's session that way. The suggestion is meant to be run after the fact. I'm just seeing correlating spammer info in my logs, and want to help flesh out the spammer patterns :)


Definitely wait for a better API from the site :)


Take your time man, we all appreciate the work you're doing! :)

yeah, parsing HTML that could change at any time, is a real horrible way to get reliable information

One question: Where can I see this part?
Is this on a user's profile page or...?
I edited the rights for my admin group to yes.

You cant and you wont be able to do that until v0.7 and then it wont be with the XML postbits.

The code that I have now is displaying all this information but I need to complete more code before I release it.

ok, I see - no problem.

So interesting change of events, the past couple of days have been very quiet from a SPAM registration stand point. I have, however, started getting a few spam messages through the contact us form.

This leads me to the request of a modification:

Optional settings to check SPS on:

* Contacts

and for folks that were deemed good during registration, but were sleepers:

* Posts
* PMs