3

We're running a WordPress site with WooCommerce. A third party plugin was injecting (sbjs_*) cookies into our site to track purchases and provide us with additional reporting. Unfortunately, something's gone wrong with the plugin and all web requests with sbjs cookies set result in a 403.

To fix this issue I've disabled the plugin, however, the sbjs cookies have an expiry of 6 months, which means all visitors who've visited us before, have cached the cookies, and get the 403 error.

  1. How do I remove the bad cookies from all requests, but leave the cookies needed for WooCommerce and our payment gateways, etc.

    I've tried .htaccess:

    RewriteCond %{HTTP_COOKIE} sbjs_migrations|sbjs_current_add|sbjs_first_add|sbjs_first|sbjs_current|sbjs_udata
    RequestHeader unset Cookie
    

    However, this of course kills all cookies, which I don't really want to do as it breaks other functionality.

  2. How do I expire those cookies, so that anyone visiting the site who has the cookies, will have them erased before their expiry date? (ie something in the page header?)

1
RewriteCond %{HTTP_COOKIE} sbjs_migrations|sbjs_current_add|sbjs_first_add|sbjs_first|sbjs_current|sbjs_udata
RequestHeader unset Cookie

Note that RewriteCond (mod_rewrite) and RequestHeader (mod_headers) are unrelated.

You need to modify/edit the Cookie HTTP request header to remove just those specific cookies, which you can do using the RequestHeader directive with the edit parameter to perform a "search and replace". For example:

RequestHeader edit* Cookie "\bsbjs_[a-z_]+=[^;]+(; )?" ""

The above applies the regex \bsbjs_[a-z_]+=[^;]+(; )? to the Cookie header (ie. to match cookies that start sbjs_) and replaces all instances with "" (ie. an empty string), essentially erasing that cookie from the Cookie header. The * in edit* ensures that all instances are replaced, not just the first one.

Reference:

Note that this doesn't strictly "expire" the cookies on the client (although that is how it appears to the application). The cookies set on the client machine are unchanged and sent with every request and so will still be left to expire in 6 months time (or whenever). The above directive simply prevents these cookies from reaching your application.

To actually expire these cookies on the client you would need to send back a Set-Cookie header with an expiry date in the past (which you could do from either WordPress/PHP or .htaccess - but note that WP would override .htaccess in this instance). However, you would also need to set/expire the cookie using the same URL-path and domain as used when the original cookie was set, otherwise, this will have no effect.

However, it does seem a bit odd that even after disabling the plugin, the very presence of these cookies triggers a 403 - there would seem to be another plugin (or something) that is doing that?

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.