Skip to main content
Topic: StopForumSpam (Read 1669 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

StopForumSpam

I'm creating this thread mostly for myself and for others to help contribute with porting the SFS mod to ElkArte.

My Github for porting SFS to ElkArte is here.

Feel free to post and such about the module here.

Re: StopForumSpam

Reply #1
OK, so here's my initial analysis of the code that SFS for SMF uses.

If you check out the original branch I set up... you'll notice that the hand-edited code that was posted as per the SMF mod's parse link for said mod... it requires modifying several files that ElkArte does not use anymore.

I'm thinking that some of this will have to be moved to a new file. And then either an integrated hook via the hooks function to pull in SFS or also hand-editing index.php as it seems that index.php may potentially have some registration handling code.

Keep in mind this is just my initial analysis and I may be hilariously wrong. But these are my opening thoughts on the matter of porting this over to ElkArte.

Re: StopForumSpam

Reply #2
First hint: you can put the function SpammerCheck into its own file, so it's one edit less already.
The edits to $sourcedir/ManageRegistration.php can be replaced using a hook (integrate_modify_registration_settings).
The edits to $themedir/Who.template.php can be avoided by using the <credits> tag in package-info.xml or using a hook again (there is a discussion going on about that).
What's left is the actual check in $sourcedir/Register.php that can of course be applied using a hook, but at the moment I'm not sure which one, this evening I'll have a look (unless someone else beats me :P).
Bugs creator.
Features destroyer.
Template killer.

Re: StopForumSpam

Reply #3
First hint: you can put the function SpammerCheck into its own file, so it's one edit less already.
The edits to $sourcedir/ManageRegistration.php can be replaced using a hook (integrate_modify_registration_settings).
The edits to $themedir/Who.template.php can be avoided by using the <credits> tag in package-info.xml or using a hook again (there is a discussion going on about that).
What's left is the actual check in $sourcedir/Register.php that can of course be applied using a hook, but at the moment I'm not sure which one, this evening I'll have a look (unless someone else beats me :P).

Ah, good, so I was thinking correctly in that the function SpammerCheck can be placed into its own file and called for by another, like say the integration hooks.

I'll toss out the Who.template.php code as I'll be using package-info.xml to add the proper credits. There's no reason for me to rewrite the code when that can be achieved by using package-info.xml.

I was mostly working on analyzing Register.php and where it'd go. It looks like I can go either way, e.g., either as an integration hook or as a direct edit to Members.sub.php as I was able to track down where ElkArte handles its registration stuff.

I tend to typically analyze the code and where and what can be safely ported. It's nice to get confirmation that my initial thoughts're more or less on the right track before I go and blow things up... lol

Re: StopForumSpam

Reply #4
Of course code edits are always possible, though if an hook is available, it's much much better to use it. Hooks are usually "portable" among versions and have less chances of conflicts installing multiple addons.
Bugs creator.
Features destroyer.
Template killer.

Re: StopForumSpam

Reply #5
Of course code edits are always possible, though if an hook is available, it's much much better to use it. Hooks are usually "portable" among versions and have less chances of conflicts installing multiple addons.

What's the best recommendation as far as an integration hook? You'd briefly mentioned you'd look into which one was the best one.

I think I'll go with integration hook over that of direct code edits... for a fairly obvious reason. I don't really want to modify core unless I absolutely have to... and in this case, I don't think I need to make such direct modifications.

Re: StopForumSpam

Reply #6
I would try to use integrate_register_check.
I think it could be handy to check if the registration is actually a guest or an admin trying to register an account:
Code: [Select]
if ($regOptions['interface'] == 'guest')
{
    // do checks
}

I'm not sure it is worth using $reg_errors to send the guest back to the registration page instead of sending a fatal_lang_error.
Bugs creator.
Features destroyer.
Template killer.

Re: StopForumSpam

Reply #7
I would try to use integrate_register_check.
I think it could be handy to check if the registration is actually a guest or an admin trying to register an account:
Code: [Select]
if ($regOptions['interface'] == 'guest')
{
    // do checks
}/code]

I'm not sure it is worth using $reg_errors to send the guest back to the registration page instead of sending a fatal_lang_error.

Why's that? Also, just moved the SpammerCheck function into SpamCheck.php and made a minor edit to the function to check for Subs.php instead of Subs-Package.php. I've not tested the code yet as I'm still in the process of setting up a development environment to make sure this actually works as intended.

That commit is 99be59a

ETA: Whoops, noticed we have Package.subs.php within the subs dir inside sources/. Obviously, I've corrected the code.

Re: StopForumSpam

Reply #8
Why's that?
The function to create a member is shared between the two different possibilities:
1) a guest registers,
2) an admin creates a member from the admin panel.
I guess admin do not create accounts that may look like spammers, or, if they do, it is intended.
Let's assume an IP is banned on StopForumSpam, and by chance (like happens more often than it should to me) that IP is a dynamic one previously used by an infected computer. If I get assigned that IP and your addon applies to the admin registration process as well, I will not be able to create new users until I disconnect and re-connect the modem (and hopefully get a new IP).
Bugs creator.
Features destroyer.
Template killer.

Re: StopForumSpam

Reply #9
Why's that?
The function to create a member is shared between the two different possibilities:
1) a guest registers,
2) an admin creates a member from the admin panel.
I guess admin do not create accounts that may look like spammers, or, if they do, it is intended.
Let's assume an IP is banned on StopForumSpam, and by chance (like happens more often than it should to me) that IP is a dynamic one previously used by an infected computer. If I get assigned that IP and your addon applies to the admin registration process as well, I will not be able to create new users until I disconnect and re-connect the modem (and hopefully get a new IP).

The latter case of dynamic IPs're definitely more likely.

I will most likely try integrating it with the guest registration process as that is the most likely source of spammers trying to get in... because 2. as per your thought if an admin creates a spammer, they're doing it for a specific purpose. So we won't go for the admin end... well, other than providing an interface in the admin backend to check and confirm, "Yup, them thar be spammers, boot 'em out!"

Though to be honest, I don't think that'd be quite necessary as we have http:BL and bad behavior. But still, it's nice to have additional options for the rare cases where they slip through.

Re: StopForumSpam

Reply #10
Just to be clear, I didn't mean to add a new option, The "interface" part is already provided by Elk itself, so it's just a matter to do a check in your the code, really just the line I wrote above. ;)
Bugs creator.
Features destroyer.
Template killer.

Re: StopForumSpam

Reply #11
Just to be clear, I didn't mean to add a new option, The "interface" part is already provided by Elk itself, so it's just a matter to do a check in your the code, really just the line I wrote above. ;)

... Oh. Well, then! :P

Re: StopForumSpam

Reply #12
Hmm. What're the equivalents of the following:

Code: [Select]
1.	Execute Modification	./$sourcedir/Register.php	File not found
2. Execute Modification ./$sourcedir/ManageRegistration.php File not found
3. Execute Modification ./$themedir/Register.template.php File not found
4. Execute Modification ./$themedir/Who.template.php File not found

for ElkArte? I think once we change this, SFS should work... but I'd need to test this further.

Edit: I'm kind of an idjit, forgive me. I'm still working on wrapping my head about SFS... after not having touched it for a while.

Interestingly, the mod can be added to ElkArte's Package Center with little to no issue... at least, right up until you try to install it. Which causes the above error, naturally. So, for the most part, the code seems to work without too much of an issue... with the obvious need to modify the SFS code to point at ElkArte functions and such.

Edit2: Ah, discovered where Register.template.php is. It's in
Code: [Select]
themes/default/Register.template.php

Edit3: Making progress. Kind of. I've now got it to correctly detect the location of Register.template.php... we'll have to obviously correct the code to work with ElkArte, though.

Re: StopForumSpam

Reply #13
Unfortunately you may have focused on the "worse" modification. The one called Stop Forum Spam hasn't been updated in years and doesn't use hooks. The mod called Stop Spammer relies primarily on hooks and offers other desired features such as reporting spammers to the SFS database. I'd convert the latter for reasons of both functionality and practicality.

Re: StopForumSpam

Reply #14
Is this the same addon?
http://addons.elkarte.net/security/StopForumSpam.html

I have just installed the recently updated addon.
What exactly does "Threshold level for spammer detection" mean? Which value/number is recommended?
ElkArte version: 1.1.3 / Theme: BeSocial