Hello again XOOPS lovers,

Does the enabled stopforumspan.com auto-lookup and block feature of protector check and block someone(thing) from signing up if they come from a known spam IP or host?

Or does it only block when they go to post content from the banned IP/host?.

Quote:
Yes, not only on register, it checks every POST request. Comments, contact forms, etc

Great news. In my 2.5.1 days (before this feature existed in profile), people would create accounts manually from what turned out to be spam IP's to get past the captcha (possibly was a captcha resolviing smart bot) and then configure spambots with the authentication.

This gets em on both ends.

Thanks for answering this Trabis.

Quote:
yes. some month ago my IP was banned by sfs and i have issues in all xoops sites that enabled sfs.

In my country many IPs are shared and it would be an issue if you enable such a global protects.
personally i prefer to implement other protections like some wise captcha.

It would be great If we can have a chance in the future xoops versions to have a profile module with a customizable registration page with the ability to add some Q/A by the webmaster that randomly displayed.

then webmaster of the site can protect the site from robot registrations

eg for xoops.org (this site):

Q:what is the first registration step name?
A: basic

Q: how many fields are required in the registration process in this site:
A: 4

with more thinks you even can find more sophisticated Q/As

Quote:

Down the road I have some ideas for a new profile module and what you mention here is one of the many features to defeat robots I will be adding.

Another idea is randomizing fields and their names. The fields can then have pictures for labels or text or if both exist randomly use one. Unless someone writes an intelligent bot that can scan pictures, the items I plan to add to profile will make it next to impossible to use an automated bot to log in. Also the use of invisible fields that are "traps" for lazy bots as well. (Use a generic field name for the real password field for instance and have an invisible "password" field that will determine this is a bot if the password field is returned.)

I probably wouldn't suggest using the password, name, or user name fields since those generally are auto filled by some browsers.

I just have to have time to work on it...

I will be writing a new profile system from the ground up. This new profile module will be stripped down to a basic core and things will be added with a plugin system. So the data sets used in the profile will all be plugins as will any other system such as authentication etc. This will allow features to be added very simply without rewriting the main program. This module will likely make some of the more complicated social modules like yogurt obsolete by using plugins for desired features.

I have a basic design in my head but I need to do more "demolition" of the profile module to solidify my design and learn more about plug in systems before implementing the design. I figure that the experience I will have gained by the time I get to it will allow me to write a very flexible profile module in a short period of time. (The database work I am doing now and the Install script will take me a LONG ways here..)

(I have basically 5 projects ahead of this with one almost done. I am including xroster in as part of the profile project since my xroster will be more of a "profile lite" that will allow people to exist in the profile that don't exist on the system so you can use it for a company Rolodex etc. )