• Resolved thomastolkien

    (@thomastolkien)


    The latest version of your plugin is changing the Cloudflare.com dashboard Browser Cache TTL setting to “respect existing headers” – uncommanded and without permission.

    Not sure if this is an intended behaviour of your plugin, but pretty sure it will violate Cloudflare’s API terms of service since it is changing the setting on a Cloudflare’s customer dashboard without permission.

    I’ve tested and replicated this on 4 client sites that use your plugin. The behaviour only occurs when updating from 4.6.0 to the latest update 4.6.1.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Contributor iSaumya

    (@isaumya)

    The latest version of your plugin is changing the Cloudflare.com dashboard Browser Cache TTL setting to “respect existing headers” – uncommanded and without permission.

    – The plugin used to do that from v1 and nothing new in the latest version. When setting up the plugin for the foiirst time it set the Browser Cache TTL to resp[etc existing header value. But if any user make any changes to that value, we highly rec ommend to ensure that the browser cache TTL is always set to respect existing header value.

    Not sure if this is an intended behaviour of your plugin, but pretty sure it will violate Cloudflare’s API terms of service since it is changing the setting on a Cloudflare’s customer dashboard without permission.

    – When you use this plugin and provide the API key/token, then you give permission to the plugin to change a few things in your Cloudflare account in order for the plugin to work properly and caching to work properly.

    The plugin only does a handfew things in your CF dashboard. First changing the Crowser Cache TTL value and then either adding page rule or worker depending on which option is selected in the plugin settings. This is why the plugin ask for your CF API Key/Token.

    The behaviour only occurs when updating from 4.6.0 to the latest update 4.6.1.

    – As I said there is nothing special done in the v4.6.1 to do this. The reason this is happening because when you upgrade to v4.6.1, during the upgrade process the plugin disable/enable the page caching at the backend to ensure all parts of the system is properly updated during the update process.

    Now if you have manually set the browser cache ttl to something else beside what the plugin recommends, then during the disable/emable page caching process, that value got set by the plugin which the plugin recommends and sets i.e. respect existing header.

    I hope this clarifies your doubts.

    Thread Starter thomastolkien

    (@thomastolkien)

    – The plugin used to do that from v1 and nothing new in the latest version.

    No. The issue is as reported and occurred only on the latest update.

    This issue has been reported in good faith as a courtesy since users may find this plugin behaviour undesirable. And it probably does violate the Cloudflare TOS, if you care to read that document – which would be unfortunate since your plugin is a very useful tool. It’s entirely up to you whether you want to act on the issue as raised.

    Plugin Contributor iSaumya

    (@isaumya)

    Hi,
    In case you don’t believe me regarding this behavior was in the plugin since the beginning, you can go to this page: https://ww.wp.xz.cn/plugins/wp-cloudflare-page-cache/advanced/ download an old version of the plugin and fresh install it on a site. If that site is already using the latest version of this plugin make sure that you deactivate and delete it from the wp-admin plugin section first before installing this old version.

    You will see that it will still set the browser cache TTL to Respect the Existing Header value as that is needed for the plugin to work. Cause the way the plugin works is setting the header values and asking Cloudflare to obey that values.

    P.S.: This matter is also mentioned in the plugin page FAQ: https://ww.wp.xz.cn/plugins/wp-cloudflare-page-cache/#what%20happens%20to%20the%20browser%20caching%20settings%20on%20cloudflare%3F

    • This reply was modified 4 years ago by iSaumya.
    • This reply was modified 4 years ago by iSaumya.
    Thread Starter thomastolkien

    (@thomastolkien)

    Not resolved.

    I was trying to help you here.

    Your plugin is useful, but it does break Cloudflare’s TOS.

    Perhaps reflect on this.

    Plugin Contributor iSaumya

    (@isaumya)

    Hi,
    It does not break the TOS of Cloudflare as this plugin clearly states that once you provide your API details, it will do the necessary config for the plugin to work properly. If the plugin did not have to do that, why will it ask for your API details?

    In fact inside the plugin settings at the time of setup, instead of API key if you select API token, it will specifically tell you the exact permissions you need to provide for the plugin to work. So, you can see which part of your Cloudflare system the plugin will handle.

    Unfortunately in order for this plugin to work, it will need to make those changes and they are clearly mentioned.

    P.S.: Please note that the plugin is not doing anything in any unauthorized way. When you enter your API details into the plugin, the plugin is just automating the things that the plugin would need but instead of manually doing, it is being automated. But from the granular level, you are doing it. I mean instead of using the plugin you could have used other system like Postman to make the same API calls to make the same changes. But to the Cloudflare system, it will remain same – as the changes have been made via API call using your Global API key.

    That is why the plugin needs either the Global API key or API Token.

Viewing 5 replies - 1 through 5 (of 5 total)

The topic ‘Latest version is changing Cloudflare dashboard Browser Cache TTL’ is closed to new replies.