Jump to content

spam on contact form

akoylini

By akoylini
in General topics

 Share

Recommended Posts

  • 2 weeks later...
  • 1 month later...
  • 1 year later...
  • 2 years later...
obewanz Rookie

obewanz

Posted
Posted (edited)
On 3/18/2018 at 8:29 AM, bellini13 said:

http://build.prestashop.com/news/fighting-against-spamming/

Actually, there are things that CAN be done beyond any third-party CAPTCHA or touring test code to defeat spammers, and it's really not that complicated. I've actually been doing it now for about 2 years and my spam messages have dropped to about 1 manually sent spam message every 3 or 4 months, acceptible in my operation.... Way better than the 40 plus per day I was receiving before sitting down and figuring out these measures. Too bad the PS coders won't look back on their best software product PS 1.6. Of course, that would also imply that Prestashop support it's software and fix defective code algorithms for free, even for that disgusting, antiquated, outdated, feature rich - not stripped down 1.7 version garbage code, Red-Headed Step-Child variant Prestashop 1.6.x. But then again, I suspect that is WHY so many merchants have resisted moving to their 1.7 release - I know it has been the driving factor for me and at least 1 other shop owner that I personally know. Also, why rely on a third-party (google) to block advertising information when that is IN FACT their business model - selling advertising data?? I don't trust google, but since they are still king of the hill with regard to search engine traffic we have to put up with them - but that doesn't mean we have to give them more of our valuable data for free by activating their plugins or "services" on our webstores!

That said, until I figure out a way to protect the code that actually does the testing (and do it for free), I can't release my solution. So why did I even mention it? Because I'm tired of hearing all of the pathetic excuses from software code managers, companies and their programmers about WHY they CAN'T FIX things that are wrong with their software without pushing you to a NEW version that either reduces the features you had (this seems to be a habit with the PS folks) or charging you additional monies (also a habit with the PS folks) or pointing you to third-party tools that will further enhance your dependence on someone else!... and I might add that Thirty Bees isn't much better, however the TB code base SHOULD have been the basis for a 1.6.4.x or 1.7 version of code for Prestashop - IMHO. Not the pathetic excuse for a release that 1.7 is - seriously, if you couldn't take the time to move the ENTIRE presentation layer over to Symfony and Twig, then why even bother?? Incidentally I don't like the Symfony platform - it's much more complicated than Smarty - and I don't see a valid reason to make such a drastic move in the code base. Thirty Bees actually proved that. Oh, you can make whatever claims you want about the change, but the fact remains that users of 1.7 really haven't gained anything except a much steeper learning curve in making custom modifications to the presentation layer of the software - ie. their templates, and a loss of essential features. But I digress...

Now that I've bashed Prestashop for the shortcomings they can't seem to wrap their heads around, and the reason why many PS shop owners I've spoken with seem to have a love-hate relationship with Prestashop itself... Let me give you a few positives. The Prestashop 1.6 e-commerce system/platform is quite possibly one of the most comprehensive and complete solutions available, especially in Open Source, and if you can live with the few shortcomings that seem to be baked into the code base, it is far superior than the hosted Shopify, BigCommerce, OpenCart, etc. solutions that I know of - in my opinion. So who the heck am I to make these comments? Nobody really, just a Prestashop 1.6 Shop Owner whose shop handles a 16k plus item catalog with over 150k product images, averaging between 30GB and 40GB per month in data traffic, and a theme template that changes the look so much that you wouldn't even know the store was driven by a Prestashop codebase, and taking orders on a daily basis 24/7 -- all (currently) running on a shared hosting server - and the only reason I MAY be forced to move to a Virtual Private Server in the near future is because of PHP changes (also a thorn in my side) and that the PS folks have dropped the 1.6 code base, so no PHP fixes forthcoming - though I am seriously considering doing my own fork for this very reason. (I also forgot to mention I'm using Panda 1.2 theme, which is more like an "engine" over the core code - but they have also gone mad with supporting mobile first code in their 1.5.5 release that doesn't work as well on non-mobile devices and also obsoletes much of the css descriptors from previous versions.) That said, I don't want to be a programmer - I want to focus on running my business - and therein lies the whole problem with where we are now! -- -- PRESTASHOP ARE YOU LISTENING??

I didn't start this response off with the idea of bashing Prestashop, but I also didn't plan on promoting these two developers either. But as I wrote out my scathing commentary on the management/methodology behind Prestashop (note that I praised the product, just not the way the business is operated from the strategic and coding perspective) I felt it the right thing to do to offer up some sort of REAL solutions. So this is my recommendation -- There are TWO absolutely Great developers out there, I have zero connection to them other than having seen their free code and implemented some of it to my own websites, as well as purchasing a module from one of them, and those two folks are Fabio from http://nemops.com/ and Milos Myszczuk aka VEKIA from https://mypresta.eu/. You may have seen Vekia on the forums - solid guy! Anyway, go direct to either of these two developers' sites and engage them with your problem. Know up front that you WILL have to pay for their services, but I feel confident in saying that whatever they come up with for you, if you don't tie their hands, it will probably be quite affordable as they can also offer those new features or "fixes" to other shop owners, thereby reducing the cost to any single owner/operator. Based on my limited knowledge of their operations, that seems to be the way they operate - and I applaud that concept.

Oh, and let's not forget about the problem that brought us all here in the first place... Spam Mail via the Contact Form - Here's Fabio's solution, though I have added my own modifications from my own codebase (some of my code for this particular override is provided after the link to his article on how to address the problem):

http://nemops.com/blocking-spam-emails-in-prestashop/

  

class ContactController extends ContactControllerCore
{
    public function postProcess()
    {
        if(Tools::isSubmit('submitMessage')) {
 
            $banned_in_email = ['.ru', 'qq.com', '.vn','ggsuppliesstock.com'];
            $banned_content = ['email marketing'];
 
            if (in_array(trim(Tools::getValue('from')),$banned_in_email)){
                $this->errors[] = Tools::displayError('There is a problem with your email address - message not sent.');
            } elseif (in_array(trim(Tools::getValue('message')),$banned_content)){
                $this->errors[] = Tools::displayError('Junk Mail score exceeded - message not sent.');
            }
        }
        parent::postProcess();
    }
}

If you're going to attempt to apply this to your site by yourself, I would suggest that you refrain from providing error messages that tell the spammer exactly WHY their message was rejected. Why help them figure out how to defeat your protocols? I just simply use a message like "Junk Mail score exceeded..." to let them know they need to try, try, try again. Make THEM waste THEIR time with trying to communicate with you and they will go away, all by themselves - because like you, time is valuable to them as well.

I no longer track the attempts to send spam content via my contact form but when I did, it cost them dearly, as in 100s (sometimes 1000s) of failed attempts before they would give up, and some of those you know they had to manually modify. I also have code that filters the form itself along with some other processing protocols, but that is the part I can't expose as it will only provide a method for them to eventually exploit the fix I have found. And NO you can't have it... Sorry, see earlier paragraph, but the code I provided here should go a long way in eliminating much of your spam. I could possibly be interested in further collaboration if someone writes the code to either read the arrays from a text file on the server or from the database, I do have a store to run.

I know this post is lengthy, but I think it covers all aspects of why this should not be a problem, but is... and something you can do to curb the problem at least a little bit.

Good Luck!

 

Edited by obewanz
typos (see edit history)
  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...