[Escalated to 2nd Tier] Access Plugin Causes Issues for WooCommerce Rest API Authentication

[Author]

Posts

[dominicV]

I am trying to: I am not specifically trying to use the Access plugin for anything here, but I am using it on a site where I now need to make use of the WooCommerce API. I believe this is a conflict.

Link to a page where the issue can be seen: N/A - this issue occurs when trying to use the API from elsewhere.

I expected to see: The WooCommerce API working as normal, at least while nothing has been set in Access to interfere with normal permissions related to products, orders, coupons etc.

Instead, I got: The WooCommerce API returns it's normal 401 related errors.

I have tested this on a brand new install of WordPress with minimal plugins installed so hopefully easy to replicate, here are the steps:

- Set up WordPress with Toolset Types, Access and WooCommerce installed and active
- Go to WooCommerce > Settings > Advanced > Rest API and set up new credentials
- Make a call from an external source, e.g. Postman, either of the following produces the same:

- GET hidden link
- Set authorisation to Basic Auth using Consumer Key as username and Consumer Secret as the password
- Instead of the product list you get:

{
"code": "woocommerce_rest_cannot_view",
"message": "Sorry, you cannot list resources.",
"data": {
"status": 401
}
}

Or:
- GET hidden link
- Instead of the product list you get:

{
"code": "woocommerce_rest_cannot_view",
"message": "Sorry, you cannot list resources.",
"data": {
"status": 401
}
}

Either of which should be fine according to WooCommerce:
- hidden link

If you deactivate the Access plugin and run either of the above it returns the product list

I did see this thread, but since it was 2 years old I thought I'd raise a new ticket:
- https://toolset.com/forums/topic/woocommerce-api-problem/

Thanks,

[Christian Cox]

Got it, thanks for the detailed information. I am able to replicate this on my local environment as well, so I'm escalating the issue to my 2nd tier support team for further investigation. I'll let you know what I find out.

[dominicV]

Great thanks! And no problem!

OK will wait to hear that. If you or they find anything I can do to work around this in the meantime please let me know. I hate playing around with capabilities (hence why I love Access) so don't really want to look at removing it from the project, even for short term.

For right now I might need to look at programmatically deactivate and activate the Access plugin for Woo API calls (since actually I'm needing to proxy them all anyway).

[Christian Cox]

Our developers have released a patch for this issue. You can find instructions for installing the patch file here: https://toolset.com/errata/a-conflict-between-the-toolset-access-plugin-and-woocommerce-rest-api/

[dominicV]

Legendary, thanks so much for this. Is there a way to subscribe to these tickets so I can keep any eye out for when the fix will be included in an update? Or can I assume it'll be in the next version?

[Christian Cox]

I haven't received final word this will be included in the next release yet. In the meantime, you should continue to get automatic updates through the forum when this ticket is updated. I'll let you know if I get a more concrete answer about the permanent solution.

[dominicV]

OK awesome thanks Christian.

[dominicV]

Hi Christian,

FYI - have been running with this patch for a few days but I think that it is actually disabling Access features for all WP REST API calls, not just WooCommerce.

A little bit harder to give repro instructions for this, since the set up I am working on for this project is very custom, but in summary this is where I started noticing the issue:

- User is signed in at Subscriber level
- User attempts the following API call:
- GET hidden link
- API returns:

{
"code": "rest_invalid_param",
"message": "Invalid parameter(s): status",
"data": {
"status": 400,
"params": {
"status": "Status is forbidden."
}
}
}

- Update Toolset Access settings to allow Publish, Edit Own, Delete Own and Read for custom post type Services
- Re-run API call, API returns the user's privately published services
- Replace types-access/application/controllers/main.php file with hot fix file and re-run API call, API returns:

{
"code": "rest_invalid_param",
"message": "Invalid parameter(s): status",
"data": {
"status": 400,
"params": {
"status": "Status is forbidden."
}
}
}

I haven't had a chance to dig in to what changes were actually in that fix, but looks like when it's in my settings are ignored for my custom post types as well.

Cheers,

[Christian Cox]

Okay thanks for the additional information, I will relay this to our developers and give you some feedback as soon as possible.