[baardarswingclubParticipant]

Hi,
We’re using cornerstone to edit our site, but it keeps getting us blocked from our hosting service because apparently it is sending 3-4 request per second to the servers. According to them, it is the cornerstone-plugin that is the issue. This has happened to us once before on another site as well.

Page: http://www.bardarswingclub.no
Word Press version: 4.4.4
X version: 4.3.4
Cornerstone: 1.1.3

[DarshanaModerator]

Hi there,

Thanks for writing in! Can you post the detailed information that you received from your hosting provider? So that we can forward it to our developers to see what we can do on our end.

Don’t forget to select Set as private reply. This ensures your information is only visible to our staff.

Thanks!

[baardarswingclubParticipant]

Hi,

According to our hosting provider, Cornerstone is making a lot of requests in a very short timespan, which triggers the DoS protection of the provider.

The requests are coming from the Cornerstone page builder / live editor, and seem to involve previewing of individual elements:

www.site.com 123.123.123.123 - - 2016-09-05T15:34:14+0200 142777 "POST /wordpress/wp-admin/admin-ajax.php?action=cs_render_element HTTP/1.0" 200 724 "https://www.site.com/some/page/?cornerstone_preview=1" 3 - 2860 1366 "application/json" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36"

As you can see the request returns a status code of 200, so the request itself is operating as normal. There are two issues here:

1. You are doing a POST request, but adding GET query arguments. I know this is allowed per HTTP spec, but according to our hosting provider, the DoS protection is extra aggressive with these kinds of requests as they are apparently used by typical DoS attacks.

   Also, the WP Codex shows the payload and action both submitted as part of the POST data:

   https://codex.wordpress.org/AJAX_in_Plugins

   Looking at the post JSON function in core.js, it seems like you can easily embed the action into the postData, at least for the useLegacyAjax mode. I’ve patched our local copy of Cornerstone to do this, and enabled useLegacyAjax unconditionally using:

   add_filter('option_cs_legacy_ajax', '__return_true', 99 );

   Hopefully that will reduce the chance that the DoS protection is triggered.

   I’m not sure when the non-useLegacyAjax mode is triggered, and if WP would be able to match the action back to cornerstone_endpoint_cs_render_element if it was embedded in the JSON, is there any documentation (WP Codex or otherwise) on how this mode works?

2. The requests from the live editor do not seem to be rate-limited in any way. It would be nice with an option to control this, for hosting situations such as our (shared hosting), where the DoS protection may be more aggressive than on a dedicated server.

Hope you can pass this on to your developers, and give us feedback on how to proceed. Thanks!

Tor Arne

[ChristianModerator]

Hey Tor,

Please disable WordPress Heartbeat API. See http://www.wpbeginner.com/plugins/how-to-limit-heartbeat-api-in-wordpress/ for more details.

Let us know if the issue persists.

Thanks.

[baardarswingclubParticipant]

Hey Christian,

I don’t think the WordPress Heartbeat API is the cause here:

1. The heartbeat it sent every 15 seconds (I just checked), but our hosting provider reported requests at a rate of 3-4 per second, sustained over a longer period, totaling to 150+ requests.
2. According to our hosting provider’s logs, all those requests where to /wordpress/wp-admin/admin-ajax.php?action=cs_render_element. The heartbeat request is to /wordpress/wp-admin/admin-ajax.php without any query arguments, as the action is part of the POST data.

Tor Arne

[JadeModerator]

Hi there,

You can try adding this in your wp-config.php located at the root directory of your site.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

You can add it before the line

/* That’s all, stop editing! Happy blogging. */

In case this doesn’t help,, kindly contact your hosting provider about your php memory limit.

Hope that helps.

[baardarswingclubParticipant]

Hi Jade,

This is not a problem with memory limits. Please read the details of the September 7 post again.

The issue is about Cornerstone making too many requests from its page builder in a short time span, in a way that triggers the denial of service (DoS) protection of the hosting provider.

Again, it’s the number and frequency of requests, with a specific profile (query arguments in a POST request), that trigger this protection, not the memory usage.

Please forward this to your developers, and let us know how we should proceed with this very specific issue.

[RadModerator]

Hi there,

Some host has built-in protection, and like you said your hosting has it. There is no particular solution since it’s decided by your security feature. Each ajax is considered connection, in every change you made they are always related to connections. Even by just loading an image, it requires a connection. There is no way we can limit the connection, it’s how the browser works. In cornerstone, we can’t combine all actions in single connection either, it will be unresponsive.

It happens on Visual Composer builder too, since it’s too uses too many connections, but more frequent and spammed than the cornerstone. Limiting connections for a site with rich features isn’t recommended. They shouldn’t just limit it, they should recognize the valid connections too.

Thanks!

[baardarswingclubParticipant]

Hi Rad (Rad name btw),

I understand that for the Cornerstone editor to work, it needs to do ajax requests to the server, that’s fine. But you didn’t answer the root cause of this issue:

Why are you doing a POST request, but adding GET query arguments?

If you didn’t add a GET argument, but baked the action into the POST data, the DoS protection of my hosts, and probably more of your customers, would not kick in as easily.

Is there any reason not to bake the action into the POST data?

Thanks!

Cheers,
Tor Arne

[ChristianModerator]

Hey Tor,

I’ve forwarded this to our core developer. Have you tried deactivating WordPress Heartbeat API though? If not, please do it.

Thanks.

[AlexanderKeymaster]

Hey there,

This is Alex, lead developer on Cornerstone. I don’t recall originally why we mixed the parameters. The major upcoming X update has necessitated some upgrades on the Cornerstone side, including a rewrite of how the AJAX handling is done. I’ll see about moving those to our master branch so they can be part of the next Cornerstone release, independent of the major update. At that point you’ll find we’re using POST exclusively, and a few things have been streamlined.

To further clarify on some points above:

Every change made to a Cornerstone element triggers an AJAX request to get updated markup. A typical editing session could involve hundreds, especially when typing, as Cornerstone tries to update between keystrokes.

Take a look at this filter:

cornerstone_render_debounce

You can pass a higher integer through it to increase the delay between updates. For example, if you return 1000, it will wait a full second before sending the AJAX request. If in that second another keystroke is made, the timer starts over. We found that 200 (the default) was optimal in most cases, but you’re welcome to adjust it if needed.

[baardarswingclubParticipant]

Yes!! Thank you very much Alex, finally a reasonable answer 🙂

Very happy to hear about the streamlined AJAX handling in the upcoming Cornerstone, hoping some of those goodies will land in master as well 🙂

Nice tip about cornerstone_render_debounce, I’ve bumped it to 500, and added a hot-patch of the core.js ajax function to move the action query argument into the POST data:

https://gist.github.com/torarnv/a732366cd3430fff72e85b71312090eb

Probably not ideal, but safeguards us for now. Will watch the Cornerstone changelog for any fixes in these areas.

Thanks again!

Best,
Tor Arne

[ChristianModerator]

You’re welcome, Tor.

[Author]

Posts