Compatibility Request: Fix WP Spamshield so it doesn't block PayPal's IPN

[joshfeck]

If you install and activate the WP Spamshield plugin and then try to post a payment back to Event Espresso using PayPal's IPN, it seems that WP Spamshield blocks the IPN. The result is the payment status for the registration is not updated as expected. This can be remedied by going to WP Spamshield's settings and checking a checkbox for "Disable anti-spam for miscellaneous forms." Once that's disabled, it works.

What's interesting about the "anti-spam for miscellaneous forms" is it's enabled by default, which tends to place the burden on the end user to figure this out, contact support, and cause a few headaches.

The plugin author suggests to use the filter hook to override their default behavior by adding something like this to the beginning of the IPN listener script:

add_filter( 'wpss_misc_form_spam_check_bypass', '__return_true' );

I tried adding the above to the handle_payment_update() and the validate_ipn() methods in EEG_Paypal_Standard.gateway.php and no go. Maybe it's an issue with the loading order?

[nerrad]

Just adding my two cents:

What's interesting about the "anti-spam for miscellaneous forms" is it's enabled by default, which tends to place the burden on the end user to figure this out, contact support, and cause a few headaches.

I think this was a poor path to take from a user perspective. This option they have enabled by default should be disabled by default with clear instructions on what may break if user's enable it (i.e. if you have any plugins that do ecommerce, it's possible enabling this option will prevent those transactions from completing).

Hopefully, someone in the EE community (or the WP Spam Shield author) will be willing to experiment with the filter they expose to discover an implementation in EE that works well to override this behaviour. We'll definitely consider pull requests for this.

However, definitely the better solution would be for the WP Spam Shield author to disable this new feature by default in their plugin.

[nerrad]

I tried adding the above to the handle_payment_update() and the validate_ipn() methods in EEG_Paypal_Standard.gateway.php and no go. Maybe it's an issue with the loading order?

Yeah likely WP_Spam_Shield is doing its thing really early. So those methods haven't probably even been called yet. It's possible we'd have to add this filter really early in the request as soon as we know we are processing an IPN (I'm not sure atm where that would be).

[ghost]

Hey guys,

Author of WP-SpamShield here. I'll be happy to help with the compatibility.

Using the hooks are very easy. Ridiculously easy, really.

The hook you'll need bypass the miscellaneous form spam checks in WP-SpamShield is: 'wpss_misc_form_spam_check_bypass'. Just add the filter when your plugin is doing its thing (during a specific action or process) and needs a bypass. (In your case, the PayPal IPN listener.) Your callback function just needs to return a value of TRUE and it will by bypass the filter. Just do a straight response of "return TRUE;" - If you need to evaluate logic, do it before you use add_filter because this should only be used to change the value to TRUE. If other devs abide by this then the priority will be irrelevant. Here's a super basic example, which you probably don't even need:

add_filter( 'wpss_misc_form_spam_check_bypass', 'your_custom_function', 10 ); /* <-- function with this should hook in early (ex 'init', -10 or 'plugins_loaded') */

You just need a callback function that's roughly similar to this:

    function your_custom_function( $bypass ) {
        return TRUE;
    }

We just ask that all developers to keep the use of this to the bare minimum...only when needed...while your plugin is doing a specific action or process, so as not to hinder any functionality. We'll finish up documentation for all this shortly. The code for the hook is very, very simple, and I'll include here if it helps at all:

    /* BYPASS - HOOK */
    $mfsc_bypass = apply_filters( 'wpss_misc_form_spam_check_bypass', FALSE );
    if( !empty( $mfsc_bypass ) ) { return; }

(You will not need to use that...that's from the WP-SpamShield plugin.)

From a security point of view, and for maximum compatibility, using the hooks is the best option.

The 'rs_wpss_misc_form_spam_check' function is hooked into the WordPress 'init' hook at priority 2. I'd recommend that the function you're using to add_filter() should be hooking either into 'init' at priority -10, or hooking into 'plugins_loaded' at any priority.

In case there is any confusion, the function that contains this below, is what should hook into 'init' at -10 or 'plugins_loaded':

`add_filter( 'wpss_misc_form_spam_check_bypass', 'my_custom_function', 10 );`

It's very easy.

I'm around to help if you need.

• Scott

---

Just to give you a little background on the feature so that it makes sense to everyone:

The PayPal IPN issue is related to a new feature we added in WP-SpamShield version in 1.8.9.9. Anti-spam for miscellaneous forms is an innovative feature that was added to protect all the random, miscellaneous, & custom forms on a site that use a POST method. Not many other plugins have a feature like this (if any). It allows our plugin to protect almost all contact form plugins seamlessly, along with any other user custom forms, and other types of forms such as MailChimp signups.

Users can disable this feature in WP-SpamShield Settings (option: "Disable anti-spam for miscellaneous forms"). For more info: http://www.redsandmarketing.com/plugins/wp-spamshield/configuration-information/#wpss_disable_misc_form_shield We note that if users have any API calls or payment gateways that get a consistent error message (they can use logging mode to verify), they may want to try using this option. We also provide info in the Troubleshooting Guide, step 13 ( http://www.redsandmarketing.com/plugins/wp-spamshield/troubleshooting-guide/ ) that if a user is having trouble with an API call or payment gateway getting blocked, they can try disabling the miscellaneous form spam protection.

That's just to give a little background. Of course we realize that leaving this solely up to users, isn't realistic. Our goal is 100% compatibility with other plugins, so we will be glad to work with you on a compatibility bridge.

---

[nerrad]

Thanks for posting here Scott. Speaking as a user of your plugin (I've used it on a number of sites), I really appreciate the work you've put into it and it works really well. However, I'm kinda baffled why you have this new feature enabled by default. Since it WILL break behaviour for users of your plugin who also have other plugins doing e-commerce, api calls and/or other misc forms happening, they wont' always be aware that its this new feature causing it. I think it's in your user's best interests to disable this feature by default and allow them to enable it with the understanding of the breakage it may cause.

Its totally your decision on what you do, but imo the users are the losers in this because they don't always know why things "all of a sudden stopped working".

[ghost]

Just to answer a couple of your concerns...

Regarding this:

What's interesting about the "anti-spam for miscellaneous forms" is it's enabled by default, which tends to place the burden on the end user to figure this out, contact support, and cause a few headaches.

From a spam and security perspective, this type of thing has to be enabled by default. WP-SpamShield is the only anti-spam plugin that can work to protect any form on a WordPress website without having code built specifically for it. Just think about that for a second. It literally works with every single contact form plugin out there, it works with MailChimp, registration forms, custom forms, everything.

I think this was a poor path to take from a user perspective. This option they have enabled by default should be disabled by default with clear instructions on what may break if user's enable it (i.e. if you have any plugins that do ecommerce, it's possible enabling this option will prevent those transactions from completing).

That's assuming that we do NO detection for ecommerce plugins or payment gateways. That would be an incorrect assumption. We do a lot ( A LOT) of detection, for PayPal, ecommerce plugins, etc. It's actually very rare that this issue comes up. We've got close to 200,000 users and very, very few issues with this. We want zero issues though, and are always improving the detection. The other thing, a lot of people forget, is that all ecommerce transactions should be happening on SSL, even PayPal. (I realize the risk is fairly low with PayPal, but its still transmitting data in the clear which is a bad practice for security.) The only sites that have the issue with PayPal IPN being blocked by this feature is site's that don't use SSL. Ones that are properly set up on SSL have no issues.

Anyway, feel free to hit me up with any questions. I'm here to help.

[ghost]

Hey nerrad,

No problem...happy to help. I'm glad you like!

I think my post above will answer your question on that. :)

[joshfeck]

The only sites that have the issue with PayPal IPN being blocked by this feature is site's that don't use SSL.

You might look into the possibility that there are sites that use SSL that have the issue. This is because the site I use for testing uses SSL. We have found that the PayPal IPN is blocked when "Disable anti-spam for miscellaneous forms" isn't checked, even with the entire site loading as https.

[ghost]

You might look into the possibility that there are sites that use SSL that have the issue. This is because the site I use for testing uses SSL. We have found that the PayPal IPN is blocked when "Disable anti-spam for miscellaneous forms" isn't checked, even with the entire site loading as https.

Will do. That is quite odd though. We have different testing criteria for SSL/non-SSL. We've never seen a legit PayPal IPN request get blocked on SSL. If there is, I definitely want to know about it. If you can turn on "Blocked Comment Logging Mode" with option "Log All Comments" and then run your test transaction it will capture the data. Please email that directly to me so I can get into it. (Please do not post online - here or anywhere else -...only send logs by email.)

[ghost]

Any luck implementing this?

[nerrad]

Scott, thanks for checking in. However, the way I see it, this is not something EE should be fixing but something better fixed in your plugin. EE works without WP Spam Shield, but when users activate WP Spam Shield then Paypal with EE ceases to work. From the perspective of users, its not EE introducing broken behaviour, it is WP Spam Shield.

I find it odd that you are insisting we implement a "fix" in our plugin when its clear from a file in your plugin class.wpss-compatibility.php that you have implemented compatibility shims for other plugins.

I appreciate the service you are providing the WP community with your plugin however, unfortunately EE users who want to use WP Spam Shield will have to continue to use the workaround we recommend which is to check the checkbox for "Disable anti-spam for miscellaneous forms."

[ghost]

Hi Darren,

I think you misunderstand the situation. We provided this fix for your benefit, not ours. You guys requested our help, not the other way around. We provided an easy fix that is 4 lines of code. Other plugin authors have been happy to implement this and have been grateful for our help. If you don't want to implement 4 lines of code, that is up to you. We provided that as a courtesy.

However, the way I see it, this is not something EE should be fixing but something better fixed in your plugin.

Typically when a plugin developer with the (vastly) smaller number of users has a compatibility issue with a plugin with a much larger number of users, it's up to the plugin developer with fewer users (that would be you guys) to make compatibility bridges. And as I have mentioned before, the better option for security is if it is done on your end.

I find it odd that you are insisting we implement a "fix" in our plugin when its clear from a file in your plugin class.wpss-compatibility.php that you have implemented compatibility shims for other plugins.

You are incorrect...I'm not insisting on anything. Saying I'm insisting on anything is insulting BTW...I have offered to help you out of courtesy. Making your plugin more compatible will help you retain users. It really won't affect us much either way.

And yes, we do have compatibility bridges for some other plugins, but these are not the same type of situation my friend...apples and oranges. You don't need to understand the reasons for each of those.

I don't think you understand what you are asking users to do when you ask them to use the option "Disable anti-spam for miscellaneous forms." You are asking them to completely disable the anti-spam for any 3rd party contact forms (and all other form types) they are using that are not Gravity Forms or Contact Form 7, so you are asking them to disable anti-spam for all of these plugins, to name a few:

• JetPack Contact Forms
• Fast Secure Contact Form
• Ninja Forms
• Formidable Forms
• Mailchimp
• Any other contact form plugin on WordPress.org
• Any other non-contact form, such as email signups
• Any registration plugin that does not use the standard registration error-check process

To users, it's simply a matter of what is more valuable to them. As all of the plugins listed above have far more users than you do, it's simply a matter of math to figure out what users will do.

I appreciate the service you are providing the WP community with your plugin however, unfortunately EE users who want to use WP Spam Shield will have to continue to use the workaround we recommend which is to check the checkbox for "Disable anti-spam for miscellaneous forms."

What is going to happen is that your users will end up switching to another events plugin, and you will lose users.

Your Event Espresso plugins have very poor ratings on WordPress.org. (Currently, Event Espresso Lite is 3.2/5 and Event Espresso 4 Decaf is 3.0/5) There are just about as many 1-star ratings as 5-star ratings. You might want to take some advice from a plugin developer who created a plugin with one of the highest ratings on WordPress.org - WP-SpamShield is 4.9/5.0 with hundreds of ratings. Just a thought.

Anyway, I've given you what you need to fix things. If you choose not to it's up to you. It's only in the interest of your users to do so. At this point, I'm not going to spend any more time on this.

Best of luck.

• Scott

[joshfeck]

We've never seen a legit PayPal IPN request get blocked on SSL.

Did you happen to look at the log I emailed you?

[ghost]

Are you guys still having issues with this? We've added more robust PayPal detection over the past year, so there shouldn't be any further issues.

If you still are having any issues, let me know and we'll be happy to help.