wc-ajax=update_order_review 403 error

This may be a good question for the host. https://www.twgreen.co/?wc-ajax=update_order_review is reachable, but a 403 could indicate something such as mod_security is blocking the request when the data is posted to the endpoint.

Why to mod_security will block the request?

Because when I first checkout the page or a use a clear browser to checkout the page. it will work fine.

But maybe later it will return 403, and can not finish the checkout process.

I found the checkout page loading first, it work fine.

But when work sometime on the same browser, it will return 403, and can not finish the checkout process.

I have a problem that the development practice the page when loading correct way is using get method. and the ajax data get usually using http get method.

But when checkout page is loading, the ajax calling of wc-ajax=update_order_review is using post method, so the web server think this ajax calling is 403 FORBIDDEN.

so why not use http get calling when wc-ajax=update_order_review request?

I found the server in nginx.
it not used mod_security.

so Why wc-ajax=update_order_review send 403 error ?

Hello did you find a solution please.. i have the same issue.. my mod_seciruty is disabled and the 403 still there wc-ajax=update_order_review send 403 error :/

Hello,

I’ve got the same error …
Wordpress 4.8.2 and woocommerce 3.1.2

Web server is Apache, and I already disabled mod_security. With no effect …
I made a test with a htaccess from initial installation, same result.
I tried another version of jquery, same result.

Does anyone have this problem ? I don’t anymore known what I could try !

Thanks a lot.

I am having the same issue. I don’t have mod_security installed and never have had it installed. My site is running on Apache on a Digital Ocean VPS. The page works so it’s not a permalink issue.

It seems like I’ve read everything that’s been tried by others on this subject, and nothing has worked. I do see a folder for fail2ban on my server, and I wonder if that could be doing a similar thing as mod_security has done on other sites.

I finally figured this out. This was only a problem when the customer logged in through the account page or the checkout page. When I cleared my cookies and then logged in through wp-login.php, I didn’t have this issue.

WooCommerce does some interesting things with login cookies and nonces, which I assume allows them to use WordPress’ user system without giving a basic customer full subscriber access.

Ultimately I needed to remove this code from wp-config.php:

define( 'ADMIN_COOKIE_PATH', '/' );
define( 'COOKIE_DOMAIN', '' );
define( 'COOKIEPATH', '' );
define( 'SITECOOKIEPATH', '' );

I believe I had added that to fix a login redirect loop, which occurred after switching my site to Cloudflare Flexible SSL. I had also added this to wp-config.php to accommodate Flexible SSL, as referenced here and here:

define( 'FORCE_SSL_ADMIN', true );
if ( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
	$_SERVER['HTTPS'] = 'on';
}

I eventually found that WooCommerce is not compatible with Cloudflare Flexible SSL, as mentioned at the bottom of their SSL FAQ page.

I ended up installing a free SSL certificate on my server using Let’s Encrypt, and switched Cloudflare’s setting to “Full (strict)”. Once I had full SSL working, I was able to remove the above lines of code from wp-config.php.

It’s possible that removing the top four “cookie” lines would have solved the issue and I could have continued using Flexible SSL. However, I had installed the SSL cert before discovering that wp-config.php was the issue. Regardless, setting up the full SSL cert is what I should have done in the first place. As Cloudflare says, “Only choose Flexible if your origin webserver cannot accept secure (HTTPS) connections.”

Finally, in debugging this issue, I came across the wc_session_use_secure_cookie filter, which is applied when the login cookie gets set and destroyed in class-wc-session-handler.php. My site seems to work fine no matter which way it’s set, but I added it to functions.php for good measure:
add_filter( 'wc_session_use_secure_cookie', '__return_true' );

Hi @dcrabill,

I’m encountering same issue as yours.

If I remove the 4 “cookies lines”, from my wp-config.php file, like you did, it solves my 403 issue.

But in this case I’m getting the login to backend issue again. Indeed, I’m working on a multisite WordPress network, and each site has its own domain.

I’ve searched for hours some solutions to fix the two problems, but I didn’t find anything…

@liomar My solution will probably only help those in the same situation as me: someone with a non-multisite install that is integrating with Cloudflare SSL. I’m sure there are other things that can trigger this problem, which you may be encountering. Things always seem to be less compatible with multisite, so that may be the sole issue for you.

One thing I’d check is how you are implementing SSL, assuming you are. Make sure the certificate is correctly installed on your server. If you are using Cloudflare, deactivate it temporarily to see if that helps. Unfortunately it’s been awhile since I tackled this, so I can’t remember any other steps I took to debug the issue.

@liomar did you a find a solution to this issue? Even I am facing this issue in a multisite WordPress environment