johanee

“… in the U.S. only.”
https://www.ads-software.com/plugins/woocommerce-gateway-paypal-powered-by-braintree/faq/

“… only available in the U.S.”
https://docs.woocommerce.com/document/woocommerce-gateway-paypal-powered-by-braintree/#does-this-plugin-work-worldwide

Followed up by:
https://docs.woocommerce.com/document/woocommerce-gateway-paypal-powered-by-braintree/#do-you-have-a-braintree-extension-that-works-in-non-us-countries

Hi,

Thanks for sending me a notice.

I’ve not seen reports like this before, and will investigate. If you have any additional information please send it my way.

Thanks,
Johan Eenfeldt

Ok, though as noted you can fix it while keeping PHP 4 compatability by switching the constructors around.

Yes, there is a bug in latest version.

On line 413 & 416 in page-links-to.php you can change “$wp_query->post_ID” to “$wp_query->post->ID”.

I’ll be working on this tomorrow afternoon CET (no computer access right now).

Can you check what urls was attempted from the access log?

Do you still get attempts? Would you be willing to run some testcode to figure out what is going on?

From version 1.7.0 there is a filter hook in the plugin to whitelist IPs.

There is an example in the FAQ section of the readme, as well as a comment in the plugin file. You’ll need basic programming knowledge.

wp_signon() should work out of the box. I’m not sure what the trouble is. If you send a copy of your login page to [email protected] I’ll check it out.

Hi,

You are right, somewhat. I’ll fix up the priority, but as you say it does not really matter. The important thing is that it runs during the plugins_loaded action instead of the init action. The later is after WP core first parse the auth cookie. That was the bug introduced in 1.6.2.

The comment is supposed to describe the fact that the plugins_loaded action is the earliest standard action available.

I’ll continue looking as this. We might still have teoretical trouble if a plugin or theme uses certain functions on their file load.

I’ve finally found an explanation for this.

There was a bug that allowed an attacker to keep trying “auth cookies” even during lockout.

See changelog of new release for more details.

And thank you for the report which started this.

Hi,

There is currently no way to change where the email notifications are sent from the Limit Login Attempts plugin.

On a multisite install it gets sent to the network admin, otherwise to the site admin.

I have it on the todo list to allow this to be changed. I’ll get to it. Eventually.

The logs are stored in the wp_options table as a serialized array.

I would not recommend modifying it unless you really know what you are doing. Perhaps you could copy the information you want to keep to an external document and clear the logs?

Anyway, the option key in question is “limit_login_logged”.

As bbPress is a normal WP plugin these days it should work, but I have no idea if anyone is using it. Apparently no one on this board.

Please contact me with your experience if you try it!

Hi,

How it works:
* the error object returned from wp_signon() on a failed login will include our error message
* when displaying the login page otherwise you can get the retries information either by calling limit_login_get_message() directly or by using the global $error like wp-login.php.

Try something like the following pseudo-code:

[Code moderated as per the Forum Rules. The maximum number of lines of code that you can post in these forums is ten lines. Please use the pastebin]

I do not think this is advisable as a general rule. I will however be adding a hook to the lockout path in the next version if anyone want to do it themselves.