/?wc-ajax=update_order_review 403

Hello @walteract,

Thanks for reaching out.

Could you please confirm if you were able to experience the same issue while all plugins were disabled, and only having Twenty Twenty-Four and Storefront as your active themes?

Hi ckadenge,

Thank you for the response.

Yes, I indeed tested with the themes Twenty Twenty-Four, Storefront, and Unero – the current theme.
At the time I only had the WooCommerce plugin active and the 403 was and still happens.

Hi @walteract,

Thanks for confirming this for us. As a next step, I’d like to understand how your site is set up.

Please share with us your System Status Report which you can find under WooCommerce > Status > Get system report > Copy for support, then paste it via https://gist.github.com/ and send the link here.

Hi ckadenge,

thank you for your help.

Here’s the gist: https://gist.github.com/walter-tavares/6dd769aea7d0a62b46bc6ab1a2fe36c5

Hi @walteract,

It looks like you’ve done a thorough job troubleshooting the issue. The 403 error is typically a server-side issue, and it may be related to a server configuration that is blocking AJAX requests.

Here are a few more steps you could try:

1. Flush permalinks: Go to Settings > Permalinks, and click on Save Changes. This can sometimes resolve the issue.
2. Check your .htaccess file: Sometimes, this file can be configured in a way that it blocks certain types of requests. Try temporarily renaming the .htaccess file, flush permalink again, and see if the issue persists.
3. Contact your hosting provider: They might be able to provide more insight into why the server is returning a 403 error. They can check server logs to see if there’s any more detailed error information.
4. Check for IP blocking or firewall issues: In some cases, the server might block certain IPs, or a firewall might be causing the issue. You could also test disabling the Defender and LiteSpeed Cache plugin for a while.

Let us know how that goes. Looking forward to helping you.

Hi Shameem,

Thank you for your answer.

1&2. I’ve seen this solution in another thread and tested it before and tested it now again. 403 is still there.

3. I’ll email the support asking for some help. The ?get_refreshed_fragments request works fine. so it doesn’t look like a problem here, anyway, I’ll take a look with them.

4. I tested the cart with only WooCommerce and a basic theme without any positive results. I’m unsure about any FW or IP blocking software, but I’ll also check support.

Another appointment that I was told to check, is to try to access the URL out of context, so I tested with postman, GET and POST methods, the results were the same, -1 in the body with a 403 code.

Thank you for the help.

• This reply was modified 8 months, 3 weeks ago by Walter T..

Hi @walteract,

Thank you for the additional details and for confirming the additional troubleshooting steps taken. Please let us know when you’ve been able to check with your host about this issue.

We’ll keep the thread open and waiting for your update.

In the meantime, I’ve also tried the checkout on your site, and I can confirm the 403 error: https://prnt.sc/ADAlTIrSaN3p. It’d be great if we could test this on a staging site with Storefront and no other plugins enabled. You can ask your host if they offer this service, too, or you can use WP Staging to spin up a new test site quickly.

Hi,

thanks for the feedback.
I’m waiting for the support response, They acknowledged the question but no answer so far.

I installed the WP-Staging, just add /woocommercedebug after the domain to enter the staging site with the request configurations.
Spoiler alert, 403 is still there https://prnt.sc/0BZY-ztE79xM

Thank you for the help, hope we can manage to fix this problem.

Greats

Hi @walteract,

The persistent 403 error, even in the staging environment, indeed suggests that this might be a server-side issue. It’s good that you’ve reached out to your hosting provider, as they should be able to provide more insight into what might be causing this issue.

In the meantime, ensure that your site’s root directory has the correct file permissions. Typically, directories should be 755, and files should be 644.

Please let us know once you hear back from your hosting provider. We’re here to help!

Hi everybody,

The problem is now solved, it was a firewall issue. I talked with the support and they solve the issue ASAP. Everything is now working fine.

Thanks to all of you that helped me to find the culprit.

Best regards

Hi @walteract,

I’m glad we were able to help! I will mark this thread as resolved. Should you have further inquiries, kindly create a new topic here.

Meanwhile, if it isn’t too much to ask for – would you mind leaving us a review here?

It only takes a couple of minutes but helps us tremendously. It would mean so much to us and would go a really long way.

Thanks!

We are using CloudFlare. And under some certain conditions it also blocked these requests under it’s “Cloudflare OWASP Core Ruleset”.

Maybe this information will save somebody else an hour in the future.

@janwoostendorp you certainly saved me an enormous headache.
Thanks a lot for the tip.