philhagen

somehow the top-level [s3] array for each _wp_attachment_metadata record was lost. I re-created them with a script and the Imgix function works again.

I should add that this is with v2.1.15.

Seeing the same thing on all 2.0.x versions including 2.0.11. Thousands of these queries per page:

SELECT image_slug FROM xxx_ngg_pictures WHERE image_slug = ‘image-443’ AND NOT pid = 0 LIMIT 1

Each page takes several tens of seconds per load, and sites with a larger number of photos take significantly longer.

This only appears to happen with galleries created *after* the upgrade, however. Galleries created prior to v2.0 still load fine. This is happening consistently on multiple sites running the plugin.

Reverting to 1.9.13 fixes this problem.

Interesting…

We have a lot of other Jetpack-enabled WP instances on the same server, and only one is throwing up this error. Therefore, I’m quite confident the problem is in the setup somewhere. I will track this down more and if it’s anything other than the client’s human error, I’ll report back here.

Definitely understand (and appreciate!) the use of OAuth versus U/P. And that XMLRPC OAuth attempts are treated the same as U/P login attempts is also good to know – helps to flag potential abuse…

Using “jetpack” instead of “username” would be helpful, FWIW, though not really critical in this case.

Thanks!

Thanks for the quick reply, Evan.

I am using custom mods to the “Simple Login Log” plugin[1] to push log messages via syslog for aggregation and active defense (fail2ban among others). I’ve received 47 login attempts to one particular WP instance since Sept 10, 2012, at a rate of around 4-5 per day on most days.

The login attempt is to the “username” user, and attempts have come from the following IPs:
– 72.233.119.245 (22x)
– 74.200.247.240 (25x)

There is no “username” user on the site, so the logins have obviously failed.

The most syslog entries for these attempts are below (all times EDT).
Oct 7 14:26:47 serverhostname httpd.itk: WordPress login: [email protected] () from 74.200.247.240 -> Failed
Oct 7 14:40:47 serverhostname httpd.itk: WordPress login: [email protected] () from 72.233.119.245 -> Failed
Oct 7 17:44:29 serverhostname httpd.itk: WordPress login: [email protected] () from 74.200.247.240 -> Failed
Oct 7 17:57:06 serverhostname httpd.itk: WordPress login: [email protected] () from 74.200.247.240 -> Failed
Oct 7 18:23:00 serverhostname httpd.itk: WordPress login: [email protected] () from 74.200.247.240 -> Failed
Oct 8 08:01:00 serverhostname httpd.itk: WordPress login: [email protected] () from 72.233.119.245 -> Failed
Oct 8 08:48:03 serverhostname httpd.itk: WordPress login: [email protected] () from 72.233.119.245 -> Failed
Oct 8 09:02:19 serverhostname httpd.itk: WordPress login: [email protected] () from 74.200.247.240 -> Failed
Oct 8 09:43:37 serverhostname httpd.itk: WordPress login: [email protected] () from 72.233.119.245 -> Failed
Oct 8 15:51:16 serverhostname httpd.itk: WordPress login: [email protected] () from 72.233.119.245 -> Failed
Oct 9 08:38:18 serverhostname httpd.itk: WordPress login: [email protected] () from 72.233.119.245 -> Failed
Oct 9 08:54:55 serverhostname httpd.itk: WordPress login: [email protected] () from 72.233.119.245 -> Failed
Oct 9 09:07:59 serverhostname httpd.itk: WordPress login: [email protected] () from 72.233.119.245 -> Failed
Oct 9 11:52:30 serverhostname httpd.itk: WordPress login: [email protected] () from 72.233.119.245 -> Failed

I don’t log the actual password value attempted, for security purposes.

Upon further review, these entries appear to be coincident with POSTs those IPs make to /xmlrpc.php[2][3]

This customer does have Jetpack installed, and my cursory review did not find any problems, though it reflects that it’s “Connected to WordPress.com” but still asking to “Link accounts with WordPress.com”. I have a feeling this means the user has not fully configured Jetpack, but nothing jumped out at me in that regard…

Let me know what other information may help nail this down – I really appreciate your assistance.

[1] https://www.ads-software.com/extend/plugins/simple-login-log/
[2] Oct 9 11:52:30 serverhostname httpd: sitename.com 72.233.119.245 – – [09/Oct/2012:11:52:29 -0400] “POST /xmlrpc.php?for=jetpack&token=<redacted>&timestamp=1349797949&nonce=<redacted>&body-hash=<redacted>&signature=<redacted> HTTP/1.0” 200 421 “-” “WordPress/3.5-alpha-21535; https://sitename.com&#8221;
[3] Oct 9 11:52:30 serverhostname httpd: sitename.com 72.233.119.245 – – [09/Oct/2012:11:52:30 -0400] “POST /xmlrpc.php HTTP/1.0” 200 422 “-” “The Incutio XML-RPC PHP Library”

Sorry to bump this thread, but I’m now seeing attempted logins for “username” several times per day from this IP.

Is this consistent with expected crawler behavior? If so, what is the reason? We use fail2ban and if the crawler keeps this up, it’ll get blocked outright.

Aha! I was testing from a post that was displayed as a recent item on the homepage.

I verified that clicking the link when on a page DOES work correctly, as well as when viewing a post on its own permalink URL.

I haven’t had a chance to test this use case, but would this be an issue when inserting the donation block into a template, where the “donate!” button would show on every page?