403 when deleting a category from a post

Is delete implemented for categories on a multisite domain?

Yes — it’s functionally equivalent to removing categories on a single WordPress instance.

I have tried basic authentication and OAuth1 access. Both code and postman return: 403 Forbidden

I can’t reproduce. I can remove an assigned category from a post by performing a DELETE request.

To confirm, you can reproduce the issue on a stock install of WordPress with no other plugins active, and Twenty Fifteen or Twenty Sixteen used as the theme?

Yes, the theme is Twenty Fifteen.
We are running WordPress 4.5-alpha-36117
This is my GET for https://example.com/mysite/wp-json/wp/v2/posts/577622/terms/category/

[
   {
      "id":15155,
      "count":0,
      "description":"AP:32624",
      "link":"https://example.com/mysite/category/ap-state-online-california/",
      "name":"AP State Online - California",
      "slug":"ap-state-online-california",
      "taxonomy":"category",
      "parent":0,
      "_links":{
         "self":[
            {
               "href":"https://example.com/mysite/wp-json/wp/v2/terms/category/15155"
            }
         ],
         "collection":[
            {
               "href":"https://example.com/mysite/wp-json/wp/v2/terms/category"
            }
         ]
      }
   },
   {
      "id":1,
      "count":0,
      "description":"",
      "link":"https://example.com/mysite/category/uncategorized/",
      "name":"Uncategorized",
      "slug":"uncategorized",
      "taxonomy":"category",
      "parent":0,
      "_links":{
         "self":[
            {
               "href":"https://example.com/mysite/wp-json/wp/v2/terms/category/1"
            }
         ],
         "collection":[
            {
               "href":"https://example.com/mysite/wp-json/wp/v2/terms/category"
            }
         ]
      }
   }
]

Is there any reason a user would have read, write, update permissions, but not delete?

(FWIW, I am only involved on the interface side of things. I don’t know the inner workings of WP)

Can you update to beta9, and see if the problem reproduces?

Is there any reason a user would have read, write, update permissions, but not delete?

They use the same permissions check, so I’m not sure how this would be possible unless there were some interfering custom code.

I am running beta9, and no other plugins, against a plain vanilla WP.

I am running beta9, and no other plugins, against a plain vanilla WP.

I don’t believe you are, actually.

Beta9 made this change:

Tags are now accessible at /wp/v2/tags, and categories accessible at /wp/v2/categories. Post terms reside at /wp/v2/posts/<id>/tags and /wp/v2/<id>/categories.

In the example provided above, your path is https://example.com/mysite/wp-json/wp/v2/terms/category.

(FWIW, I am only involved on the interface side of things. I don’t know the inner workings of WP)

It would be helpful if you could have someone with access to your WordPress instance do a bit of debugging into where the request errors. As it stands now, it’s very hard to debug what the problem is without sufficient detail.

Sorry, I wasn’t clear. I should have mentioned that have a separate instance: https://vccw.dev/wp-json/wp/v2/posts/1/categories/1
Where I still get the error.

I have full access to both instances. I guess I will keep digging and see what I can find.

Tailing tail -f /var/log/httpd/wordpress-access.log doesn’t reveal anything:
192.168.33.1 – admin [29/Dec/2015:22:46:51 +0000] “DELETE /wp-json/wp/v2/posts/1/categories/2 HTTP/1.1” 403 97 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36”

Tailing tail -f /var/log/httpd/wordpress-error.log has SSL/443 errors, even though I am using basic auth:
[Tue Dec 29 22:53:18 2015] [info] [client 192.168.33.1] Connection to child 9 established (server vccw.dev:443)
[Tue Dec 29 22:53:18 2015] [info] Seeding PRNG with 648 bytes of entropy
[Tue Dec 29 22:53:18 2015] [info] Initial (No.1) HTTPS request received for child 9 (server vccw.dev:443)
[Tue Dec 29 22:53:24 2015] [info] [client 192.168.33.1] (70007)The timeout specified has expired: SSL input filter read failed.
[Tue Dec 29 22:53:24 2015] [info] [client 192.168.33.1] Connection closed to child 9 with standard shutdown (server vccw.dev:443)

(essentially repeats)

I added these to wp-config.php:
define( ‘WP_DEBUG’, true );
// Enable Debug logging to the /wp-content/debug.log file
define( ‘WP_DEBUG_LOG’, true );
// Disable display of errors and warnings
define( ‘WP_DEBUG_DISPLAY’, true);

Which did not generate any logs or messages.

Sorry. When I said “do debugging”, I meant someone will need to step through PHP code execution in the request you’re making to see at what point the request is failing to be authorized.

Oh. I can do that too. I’ll see what I can find.

The error is occurring in /wordpress/wp-includes/rest-api/class-wp-rest-server.php at line 839

if ( ! is_wp_error( $response ) ) {
					// Check permission specified on the route.
					if ( ! empty( $handler['permission_callback'] ) ) {
						$permission = call_user_func( $handler['permission_callback'], $request );

						if ( is_wp_error( $permission ) ) {
							$response = $permission;
						} else if ( false === $permission || null === $permission ) {
							$response = new WP_Error( 'rest_forbidden', __( "You don't have permission to do this." ), array( 'status' => 403 ) );
						}
					}
				}

It’s this check that seems to be failing: https://github.com/WP-API/WP-API/blob/develop/lib/endpoints/class-wp-rest-posts-terms-controller.php#L277

Can you inspect what might be returning false in update_item_permissions_check()?

It is returning false.
I backtracked it and I believe it is due to https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-user.php#L748 function has_cap() returning false when it hits “edit_others_posts”. (It also throws false when it hits “unfiltered_html”, but I am pretty certain that is unrelated).

The confusing thing about the literal interpretation of that capability check is that I am trying to change a post that the authenticated user created.

@danielbachhuber Can you offer any advice regarding the false coming from the function above?

Can you offer any advice regarding the false coming from the function above?

It’s hard to say without having access to the codebase, and being able to debug myself. It appears your user is missing the edit_others_posts capability when they’re expected to have it.

Importantly, WordPress stores user capabilities in the database. If you’ve ever modified your user capabilities, then those changes will persist even when you disable the plugin you used to modify them.

WP-CLI includes wp role reset (ref), which you can use to reset capabilities for all of your roles.

If resetting capabilities doesn’t solve the problem for you, you’ll need to do further debugging of why the capability is returning false when you’d expect it to return true.