Woocommerce-admin: Repeated 403 across all pages

[skills-up]

Hello,

After fresh installation of the plugin on an existing WooCommerce site, I'm getting 403 errors in the console on all of the plugin pages, including the setting page.

Some of the errors are listed below:

api-fetch.min.js?ver=3.1.2:1 GET .../wp-json/wc-analytics/orders?_fields%5B0%5D=id&page=1&per_page=1&status%5B0%5D=processing&status%5B1%5D=on-hold&_locale=user 403
Show 25 more frames
api-fetch.min.js?ver=3.1.2:1 GET .../wp-json/wc-analytics/admin/notes?order=desc&orderby=date&page=1&per_page=1&type=info%2Cwarning&_locale=user 403
_ @ api-fetch.min.js?ver=3.1.2:1
api-fetch.min.js?ver=3.1.2:1 GET .../wp-json/wc-analytics/reports/taxes/stats?after=2020-01-01T00%3A00%3A00&before=2020-01-07T23%3A59%3A59&interval=day&order=asc&per_page=100&_locale=user 403
_ @ api-fetch.min.js?ver=3.1.2:1
(anonymous) @ api-fetch.min.js?ver=3.1.2:1
(anonymous) @ api-fetch.min.js?ver=3.1.2:1
api-fetch.min.js?ver=3.1.2:1 GET .../wp-json/wc-analytics/products?low_in_stock=true&page=1&per_page=1&status=publish&_locale=user 403

For now I'm disabling the plugins to prevent it from interfering with other screens (such as Orders list). Hoping that it will get resolved soon.

Thanks!

[rrennick]

@skills-up Thanks for reporting the issue. You will see that happen if you leave your browser tab open on a WC Admin enabled page over night. If you navigate to a non-WC Admin enabled page then back the page will load correctly.

This is something we should address before merge to core. The reason this happens is that the nonce is expired. After wp.data has been implemented we could add a freshness to the nonce.

[skills-up]

@rrennick Thanks for responding!

No, I'm talking about a fresh installation of the plugin causing the problem. I've not even been able to configure it in the settings page after activation. I tried going to the dashboard page and coming back to WC Admin, and the problem was still there. Given that it's 403, it looks more like some kind of a permission issue for ajax.

[rrennick]

it looks more like some kind of a permission issue for ajax.

In that case it's likely something on your server/install that's blocking it. Have you tried deactivating all plugins except WooCommerce & WC Admin?

[skills-up]

I've not tried that.

Though all other plugins are working fine, and so does all other ajax. So
why any special permissions are required for this plug-in?

On Tue, 7 Jan, 2020, 7:03 PM Ron Rennick, [e-mail] wrote:

it looks more like some kind of a permission issue for ajax.

In that case it's likely something on your server/install that's blocking
it. Have you tried deactivating all plugins except WooCommerce & WC Admin?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/woocommerce/woocommerce-admin/issues/3522?email_source=notifications&email_token=AGPTU2NY75KYZA35SQN2R5LQ4SADDA5CNFSM4KDSJSN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEII3XIQ#issuecomment-571587490,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGPTU2PJ3OE4XIIHQTIQO6DQ4SADDANCNFSM4KDSJSNQ
.

[rrennick]

So why any special permissions are required for this plug-in?

If deactivating your other plugins resolves this then there is a conflict with one of those plugins. We would like to address those conflicts if possible.

[jeffstieler]

Hi @skills-up,

Can you share what other plugins you have installed and active? Are any of them security-type plugins that might restrict access to the REST API?

Thanks!

[skills-up]

Hi @jeffstieler,

It would be difficult to compile a list of all plugins, since a lot of those are custom plugins. However, there is no security plugin being used, as we handle the security through cloudflare and firewall.

Thanks!

[jeffstieler]

Hello @skills-up,

there is no security plugin being used, as we handle the security through cloudflare and firewall

Are there perhaps firewall rules that would restrict custom REST API routes? WooCommerce Admin adds a lot of REST API endpoint (like the ones that are 403ing in your paste above).

Can you successfully make a GET request to /wp-json/wc-analytics ? If not, Cloudflare or your firewall settings may be the source of the 403 errors.

[miikapk]

Sorry to bump this thread, but it looks like I am having this exact same issue at the moment all of a sudden.

Since two days ago, I've started to have high cpu usage for a single of my site (on SiteGround shared hosting) and access logs are filled with 403 issues on the following requests:

[12/Apr/2020:08:43:40 +0200] "GET /wp-json/wc-analytics/admin/notes?page=1&per_page=25&status=unactioned&type=error%2Cupdate&_locale=user HTTP/1.0" 403 115 "https://xxxx/wp-admin/edit.php?s=25172&post_status=wc-processing&post_type=shop_order&m=0&wwpp_fbwr=all_order_types&_customer_user&paged=1"

[12/Apr/2020:08:43:40 +0200] "GET /wp-json/wc-analytics/orders?_fields%5B0%5D=id&page=1&per_page=1&status%5B0%5D=processing&status%5B1%5D=on-hold&_locale=user HTTP/1.0" 403 115 "https://xxxx/wp-admin/edit.php?post_type=shop_order&all_posts=1&paged=1"

[12/Apr/2020:08:43:41 +0200] "GET /wp-json/wc-analytics/admin/notes?order=desc&orderby=date&page=1&per_page=1&type=info%2Cwarning&_locale=user HTTP/1.0" 403 115 "https://xxxx/wp-admin/edit.php?post_type=shop_order&all_posts=1&paged=1"

[12/Apr/2020:08:43:47 +0200] "GET /wp-json/wp/v2/users/me?context=edit&_locale=user HTTP/1.0" 403 115 "https://xxxx/wp-admin/edit.php?post_type=shop_order&all_posts=1&paged=1"

My other very similar sites works properly under same hosting account. It's just this one that all of a sudden started to show these during middle of the night and onwards.

Before this started to happen, it looks to be just fine:

[10/Apr/2020:02:09:28 +0200] "GET /wp-json/wc-analytics/admin/notes?page=1&per_page=25&status=unactioned&type=error%2Cupdate&_locale=user HTTP/1.0" 200 2 "https://xxxx/wp-admin/edit.php?post_type=shop_order&all_posts=1&paged=1"

Here is an example where I've grepped one of the requests and you can see when it starts to throw 403 (it did once at night, and then constantly next morning).

https://www.dropbox.com/s/fju35kvakq794ns/picture-200-to-403-crop.png?dl=0

What I noticed that the IP addresses in all of these calls on the screenshot (I cropped them out) are my operator IP - as if I would be the call initiator.

I can call /wp-json/wc-analytics just fine.

Does this make any sense?

I did not make any changes during the time this started and I am completely lost why it happens.

Attached also status report. I have disabled almost every plugin earlier (wp-rocket caching included), and it makes no difference.

https://www.dropbox.com/s/rurta33oj23k599/status.txt?dl=0

[miikapk]

Update!

Can you imagine? I was thinking about why the IP spamming my website was within my work operator range. I had an idea after reading dozens of topics from last year that a computer that I am using to work with my website, could actually create requests constantly to the website logged in to.

I went to work and checked the IP address of my work computer - matches with the 35 000(!) requests being created only today to my website, that all ended with 403 status!

I logged back in to the admin panel, clicked WooCommerce -> Orders (this is where I left the computer on Thursday evening before I left home), and then clicked away from WC Orders to Dashboard Home. Then I logged out from wp-admin. Since then, no more 403 spamming on logs.

This is quite normal scenario in any E-commerce company where people work on orders, and then just lock their computer, and very potentially leaving browser open on WC orders page. And the result is massive request spam causing the account suspension warning.

Let me know if I can help with anything, I really hope this gets fixed (I really thought it already was!).

[debugP]

Hello,
sorry for the intrusion. I am having the same issue as miikapk
Our server went down repeatedly because of a very high number of requests on the files below
the number in the end (3.294) is the requests in around 15 hours in which one of our computers has been left open overnight with the tab WooCommerce => Orders open

#

/wp-json/wc-analytics/admin/notes?order=desc&orderby=date&page=1&per_page=1&type=info%2Cwarning&_locale=user 3.294
/wp-json/wc-analytics/admin/notes?page=1&per_page=25&status=unactioned&type=error%2Cupdate&_locale=user 3.294
/wp-json/wc-analytics/products/reviews?page=1&per_page=1&status=hold&_locale=user 3.294
/wp-json/wp/v2/users/me?context=edit&_locale=user 3.294
/wp-json/wc-analytics/orders?_fields%5B0%5D=id&page=1&per_page=1&status%5B0%5D=processing&status%5B1%5D=on-hold&_locale=user 3.293
/wp-admin/admin-ajax.php?action=rest-nonce 1.430

#

Please fix!
Thank you
Mauro

[stephhjacq]

Reported in #11097811-HC

The API calls were blocked for this user by the G6 firewall in .htaccess

Removing the following restored the dashboard data:

# Block XML-RPC requests
<Files "xmlrpc.php">
  Require all denied
</Files>

[timmyc]

For a fix here, let's bump the freshness threshold to something quite high, maybe 2 days, just to prevent the scenario of computers being left with a browser window active, and fresh-data firing off requests.

https://github.com/woocommerce/woocommerce-admin/blob/master/client/wc-api/constants.js#L13

[tharmann]

In the last couple of months, two clients experienced not being able to access their own sites (hosted at WP Engine) from their respective local offices. Upon digging into the issue, I found this very bug to be the culprit. If someone leaves a tab open to a WooCommerce Admin page, eventually the nonce gets stale and the 403's start piling up. What's unique in this case is that WP Engine will eventually block an IP generating so many 403's - this is what happened in both of my client's cases.

Now, I understand that end users should not be leaving WC Admin tabs open like this. However, we are unable to completely control what end users do - and if a public IP gets blocked for an entire office running an eCommerce store, that can spell big trouble. So, I think it would be great to work at resolving this. We could perhaps have an option that turns on and off realtime WC data in the back-end such that when turned off, a user would need to reload the page to see new data? Or maybe we could check that our nonce is still good and if not stop requesting the data?

Anyways, it's very easy to recreate this issue:

1. Log into the WordPress Dashboard
2. Navigate to a WC Admin enabled page like WooCommerce -> Dashboard
3. Open another tab to the same site
4. Log out on that tab but keep the WC Dashboard tab open - leave for a few hours or overnight (it takes a while to time out at first)
5. Watch the 403's pile up - and if you are on a host that blocks your IP (like WP Engine) watch yourself completely lose any access to your site.

[timmyc]

@tharmann Thanks for the detailed steps. We are actually in the process of phasing out the part of our data layer which triggers these requests to keep the data fresh. It is looking like that will be shipping in WooCommerce 4.5 potentially - so that will be the ultimate fix-all for this scenario.

[tharmann]

Excellent thank you!

[kmmathis]

Looks like 4.5.1 is out today, can anyone confirm if the fix for this was included?

[jeffstieler]

Hello @kmmathis, the changes that @timmyc is referencing did not get released in 4.5.1 - but should get released with the next version of WooCommerce. Optionally, you can install the WooCommerce Admin plugin when version 1.6.0 is released.

[kylehuberman]

WooCommerce Version 4.5.2 was released back on Sept 14, but was not fixed in it. What is the timeline for WooCommerce Admin 1.6.0 to be released?

[timmyc]

@kylehuberman 1.6.0 was released earlier this week and was part of Woo 4.6

[skills-up]

@timmyc has this issue been fixed in admin version 1.6.0?

[timmyc]

@skills-up indeed as of 1.6 of woocommerce admin and WooCommerce 4.6, we have fully migrated to the wp.data functionality shipped in WordPress core to do all data-level operations client-side. This new data layer no longer performs automated "refreshes" of data, so it should significantly cut down on XHR traffic to the REST API from pages like WooCommerce Analytics.