Cookies are busting my proxy cache

Hi there,

> I’m seeing that this plugin is issuing cookies on single product pages. I’m not using any payment functionality on product pages, i.e., no express checkout there.

Here is a list of all WooCommerce cookies: https://woocommerce.com/document/woocommerce-cookies/ – I am afraid there is no setting in WooCommerce that allows you to deactivate them.

> I am seeing __stripe_mid (and maybe others) get set there.

You will either have to modify the application code or maybe try a GDPR or similar plugin to control cookie usage in general.

Kind regards,

Hi Con, I think it’s worth digging a little more into this issue because it’s got huge implications.

1) I have disabled express checkout on product pages, yet, the __stripe_mid cookie (maybe even others) is set when visiting those pages. Why?

2) Moreoever, 12 external fetch requests are made to [rm].stripe.com from the product page. Why?

Why should any of these happen when express checkout is disabled on product pages? The net effect of these is unnecessary performance hit and completely disabling caching on perfectly cachable pages.

I personally think the plugin can play nicer here. But, if there’s a way to control this behavior in my own code, I would be willing to do that if you tell me how.

Thanks.

• This reply was modified 2 years, 4 months ago by mammadz.

To give you a sense of the performance on mobile (fast 3G with 150ms ping latency):

– Each r.stripe.com/0 fetch is about 650-700ms (10x some overlapping)
– Each m.stripe.com/6 call is about 600ms (2x not overlapping)
– js.stripe.com/v3/fingerprinted/js/trusted-types-checker is another 600ms

All happening on single product pages.

• This reply was modified 2 years, 4 months ago by mammadz.

Hi @mammadz

As far as I know Stripe requires that the files are loaded on as many pages as possible in attempt to help combat fraud. Are you by any chance using the payment request buttons (Apple Pay/Google Pay) ? If not, we did provide a fix some time ago to not load Stripe JS on product pages when PRBs are disabled, and to not load Stripe JS on the cart page when PRBs are disabled.You can see that, along with the new filters here:

https://github.com/woocommerce/woocommerce-gateway-stripe/pull/2110

Cheers!

Hi @rynald0s and thanks for the filters. I was able to disable loading the js on product pages. No more __stripe_* cookies either. That’s great.

However, I noticed that this plugin is also setting the wp_woocommerce_session cookie on the same product page. That is also undesirable as it gets in the way of hitting the cache. I’m not logged in, and there’s no item in the cart, so I’m not sure why this cookie is set by the plugin. If I deactivate the plugin then everything works as expected and I’m able to hit the cache.

Is there any way to disable that?

• This reply was modified 2 years, 4 months ago by mammadz.

Looking at the code in class WC_Stripe_Payment_Request, something like this would be ideal:

public function set_session() {
                if ( ! $this->is_product() || ( isset( WC()->session ) && WC()->session->has_session() ) ) {
                        return;
                }

                if ( WC_Stripe_Helper::should_load_scripts_on_product_page() )
                        WC()->session->set_customer_session_cookie( true );
        }

• This reply was modified 2 years, 4 months ago by mammadz.

Hi @mammadz ,

That is also undesirable as it gets in the way of hitting the cache. I’m not logged in, and there’s no item in the cart, so I’m not sure why this cookie is set by the plugin. If I deactivate the plugin then everything works as expected and I’m able to hit the cache.

Is there any way to disable that?

There isn’t an out-of-the-box way to disable it, however, I recommend opening an issue on Github at https://github.com/woocommerce/woocommerce-gateway-stripe/issues where the developers can take a look and provide their insight.

https://github.com/woocommerce/woocommerce-gateway-stripe/issues/2392

Thanks.

Thanks for opening the report, @mammadz .

I’ll mark this thread as resolved, you can follow along with updates/discussions from the development team on the Github report.