• Resolved markisu72

    (@markisu72)


    Hi,

    your plugin has two, three properties, which restrict its usage and creates a serious stability hazard.

    Firstly, your plugin does not rely on the WordPress-internal cron, which – besides the fact that not every provider allows for individual crons – can result in unwanted high load, since the normal cron and your cron might run in parallel unwantedly.

    Secondly, your plugin does not write logs on its own but relies on the piping the calls output to a file manually. This is really cumbersome and – again – might get restricted by security policies of a provider (understandably). In that case, you don’t get any logs for that operation.

    Thirdly – and this is the worst – your plugin requires to configure the execution time to 1h. I cannot emphasize enough, how critical this requirement is. Since it is not possible to configure that for your script only, it is a global setting. Restricting max execution time to a low number (e.g. 30 seconds) is absolutely mandatory for server stability.

    If e.g. there is a DOS or hacking attack (which happens multiple times a day), the server is able to recover from that by itself, because it will kill requests which take long due to high server load.

    Thus, after a certain time, the server comes back to life.

    With setting the max execution time to 1h, you completely bypass that security layer. It will be very easy to shoot the shop to the moon for hours.
    And then the server monitoring will kick in and restart the server automatically, completely neglecting what you wanted to achieve with that long execution time (having enough time to process your updates without interruption). The concept just does not work!

    Besides that, since your own endpoint is publicly available, you even provide attackers the best entry point to kill the server with just a few calls. If your cron runs for, let’s say 10 minutes, you just need 6 calls to overload one core for an hour. You have 8 cores? Ok, then you need just 48 requests to achieve that.

    Everyone out there can kill everyone’s server just by calling your endpoint via web browser and hitting reload a few times.

    You really need to change this urgently.
    This is baaaaaaad ??

    Thanks
    Markus

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author BigBuy

    (@devsmip)

    Dear Markus,

    Thank you for your message and your patience.

    We can see that you are already in touch with our dedicated support from our website, but in any case, we will answer here too.

    Your feedback is much appreciated and we will review it thoroughly.

    Regarding this post, let us analyse your points:

    1. The cron is created directly on the server, to allow more freedom and control on it. Our process cannot overlap, but the possibility to run multiple processes is something that can happen for many other reasons, not only for our cron and it’s out of our control for now. In any case, we are always studying the WPcron in order to check if there is really a better and consistent way.
    2. Some logs are always created by the process, but the process import cron log is optional, if it’s too cumbersome for you, you can run the cron task without the log creation part.
    3. Regarding this, we are preparing the customers for any kind of server, since we can process blocks of many products at once, some servers might be too slow to run with slower execution times. This way we are just trying to avoid issues with incomplete synchronization.

    In any case, we will continue the conversation with you in our emails and from the feedback that you have already forwarded to us.

    Thanks again!
    BigBuy Team

    Hi markisu72,

    Can you please send me an email to [email protected]!

    Thanks

Viewing 2 replies - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.