Support » Plugin: WP-Members Membership Plugin » Problems between WP-Members and Jetpack Protect

Viewing 5 replies - 1 through 5 (of 5 total)
  • Same thing here, i disabled the jetpack protect option and problem was solved.

    By the way this was with the version 2 of wp-members, i did not try the new version.

    Plugin Author Chad Butler

    (@cbutlerjr)

    As @knireis points out, it’s not related to the update – it’s any version of the plugin.

    The problem with this is that these types of plugins use WP’s authenticate filter hook to add a third value to the login that needs to be validated. But this isn’t compatible with WP-Member’s own login form (side note: this login isn’t required for using WP-Members; an authenticated user is recognized by the plugin whether the WP-Members form is used or not, it’s just that it’s easy to implement and obviously is the default).

    Because the filter these plugins use is global to the authentication process, if a 2 argument login is submitted, it will fail because there is no third argument to validate.

    The possibilities to avoid this are multiple:

    First, you could not use whatever plugin is adding a captcha to the WP login (more than just Jetpack Protect do this). There are varying opinions on this, but I’m of the opinion that captchas are not overly effective, so it’s not going to stop a brute force attack and there are better ways of doing so without degrading the UX/UI. But I know there are other opinions so this isn’t the only solution.

    Another possibility is to not use WP-Member’s login form. For this general answer I can’t detail the ways to handle this because there isn’t a single answer for this. But basically, WP-Members has filters that could be used to return the WP login form instead of WP-Members’ form, or you could use another plugin or self-built solution that adds the WP login form to the front end. These login captcha plugins are hooking into the form itself to add the captcha to the form, so if the WP form is called front end, that would have the captcha included and you could still have it enabled.

    Lastly, you could apply a filter to override what the captcha plugin is doing. Essentially, the captcha is hooking to the authenticate filter to apply it’s own process to authentication. If you add a filter hook with a later priority that reapplies WP’s own authentication function (wp_authenticate_username_password()), you’ll essentially override it. If this method is taken, I’d go a step farther an look to see if the form submission is coming from the WP native form; something that can be done by checking if ‘wp-submit’ is posted with the form, and then only apply the filter if that isn’t the case. This second step would allow you to have the backend retain the captcha while still allowing the WP-Members form to function on the front end. That would look like this:

    if( ! isset( $_POST['wp-submit'] ) ) {
    	add_filter('authenticate','wp_authenticate_username_password',99,3);
    }

    I know that looks like a lot in the way of explanation, and unfortunately, that’s really just an overview of what is happening and how to work with it based on what your desired outcome is. Hopefully you can find something in there that is worthwhile.

    Thread Starter ricesrey

    (@ricesrey)

    Thanks so much for taking the time to explain. In fact, there’s a lot of information there to digest. Chances are though–with my limited PHP programming knowledge–that I won’t be able to successfully get them to work together.

    You should consider, however, adding a fix for it to a future WP-Members update. Brute Force Protect had become quite a popular plugin before Automattic acquired it. And now that it’s part of the Jetpack package, it should gain even more popularity. It would be a shame to make people choose between using WP-Members OR Jetpack Protect since both are useful.

    Best regards,
    Ric

    I just ran into the same issue (on a test site of course…).

    Thank you for the detailed explanation of the issue, as it makes it clear what is going on in the plugins interaction.

    I would also like to suggest that you implement a change to resolve this conflict, if nothing else to be one of the “we fully support JetPack” plugins.

    Regards,
    yk11

    Plugin Author Chad Butler

    (@cbutlerjr)

    Good suggestions, both. Thanks.

    I will definitely come up with a specific solution that gets incorporated into the plugin itself (rather than a custom script). Part of the version 3 lifecycle is going to be better internal compatibility with some specific (and popular) plugins that I am running into more and more users asking questions about.

    This reverses a long standing policy to not work to support specific plugins, since I have no control over their development or how widespread their use would be. But that policy is fairly old (I’ve been developing for WP since 2005, and WP-Members dates back to 06/07) and the WordPress universe has changed exponentially since then. I’ve been planning to change my official stance on this for awhile and 3.0 was really the milestone that I planned to begin the process.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Problems between WP-Members and Jetpack Protect’ is closed to new replies.