Incorrect HTTP status code in 'posts' query.

[demitrimuna]

I am using the WordPress (v4.9.4) JSON API, specifically this URL:

http://.../wp-json/wp/v2/posts

This works great. When I request a 'status':

http://.../wp-json/wp/v2/posts?status=draft

I get this error:

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

It took me a bit to realize that the problem is not that the request (or status keyword) is in valid, but that requesting drafts requires authentication.

I'd like to request that HTTP status 401 (unauthorized) be returned instead of 400 (bad request). The request is not bad, just requires authentication.

[danieltj]

Converting to a bug considering the wrong HTTP status code is being returned here.

From a quick glance it seems as if a few errors are defaulting to a 400 error code.

[dontgo2sleep]

I am on it :)

[davidhernando]

Changes status 400 with 401 for unauthorized requests. keeps status 400 for wrong requests.

[davidhernando]

Some unit tests that had assertions checking returned status code was 400 have been changed to check that returned status code is 401.

needs-code-review

This is a refresh for 43681.diff. Has not been code reviewed.
Only for testing purposes

Trac ticket: https://core.trac.wordpress.org/ticket/43681

[SirLouen]

Test Report

Description

✅This report validates that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8991.diff

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 137.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-One 2.5
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Testing Instructions

• As provided in the OP Post

1. Go to /wp-json/wp/v2/posts?status=draft
2. 🐞 Error 400

Expected Results

1. As per specification, 401 Not Authorized is required for this, Error 400 is definitely confusing as it doesn't really specify the problem.

Actual Results

1. ✅ Issue resolved with patch.

Additional Notes

needs-code-review

• Important note: This patch has not been code reviewed, it's only a refresh
• I've added the patch as a GH PR to run the unit test suite. I might be updating if required based on the results.

[SirLouen]

I've improved the previous patch. It was not accounting for users with read_private_posts capability checking for private posts. Those were failing because it was only checking for edit_post capability.

Now all tests are passing with the refreshed patch, so its time to move into testing.

More Testing Instructions

1. Create a user, add read_private_posts capability to that user and try to read all posts with status private.

2. Then try to read all posts with a regular user with the status private. It should return 403, instead of 400.

3. Try to read with the user with capability read_private_posts posts with status draft. It should return 403 instead of 400

[krupajnanda]

Test Report

Description

This report validates the indicated patch is partially working as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8991

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.15
• Server: nginx/1.25.3
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.15)
• Browser: Chrome 137.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • PublishPress Capabilities 2.19.2
  • Test Reports 1.2.0

Actual Results

1. Issue is not completely resolved with given patch.

Additional Notes

• ✅ I tried to replicate the bug and I was able to recreate the issue in my set up.
• ✅ After checking out the code at this PR, the baseline state issue is resolved.
• ⚠️ However, 403 Forbidden is not observed in unauthorized scenarios — instead, all such cases return 401 Unauthorized.

🔍 Scenarios & Results

1. User with/without extra capabilities querying status=private:

• User created with no additional capabilities
• Sent GET request to: /wp-json/wp/v2/posts?status=private
• Expected: 403 Forbidden
• Actual: ❌ Received 401 Unauthorized

2. User with/without read_private_posts capability querying status=draft:

• Same user from scenario 1
• Sent GET request to: /wp-json/wp/v2/posts?status=draft
• Expected: 403 Forbidden
• Actual: ❌ Received 401 Unauthorized

Supplemental Artifacts

Add as Attachment

[krupajnanda]

Capabilities with private post

[krupajnanda]

Update

Test Report

Description

This report validates that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8991

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.15
• Server: nginx/1.25.3
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.15)
• Browser: Chrome 137.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • PublishPress Capabilities 2.19.2
  • Test Reports 1.2.0

Actual Results

✅ Issue resolved with patch.

🧪 Final Verification Scenarios

1. User with read_private_posts capability requesting status=private

• Result: 200 OK – private posts retrieved

2. Authenticated regular user requesting status=private

• Result: 403 Forbidden – "Sorry, you are not allowed to list non-published posts in this post type"

3. User with read_private_posts capability requesting status=draft

• Result: 403 Forbidden

4. Unauthenticated request for any non-public post status

• Result: 401 Unauthorized

Supplemental Artifacts

Add as Attachment

[SirLouen]

It seems that this patch will not move forward according to the last bug scrub

According to @rmccue this will cause backward compatibility issues. We could not get into much detail, but he said he will be explaining next week with more time all the causes and consequences, before closing this ticket as wontfix

For this reason, I'm adding close tag, waiting for him to finally close it with all the reasons.