Proxied network requests for plugin/theme api fail when using Firefox UA string #916
Comments
adamziel
added a commit
that referenced
this issue
Jan 10, 2024
….org API Solves #916 Do not merge yet. My assumption was that api.wordpress.org rejects the UA string, but it seems that it goes deeper than that. This CURL command actually works well with the same "problematic" UA string: ``` curl 'https://api.wordpress.org/plugins/info/1.2/?action=query_plugins&request%5Bpage%5D=1&request%5Bper_page%5D=36&request%5Blocale%5D=en_US&request%5Bbrowse%5D=popular&request%5Bwp_version%5D=6.4' --compressed -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H 'Accept-Language: en,en-US;q=0.5' -H 'Accept-Encoding: gzip, deflate' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' -H 'Sec-Fetch-Dest: document' -H 'Sec-Fetch-Mode: navigate' -H 'Sec-Fetch-Site: none' -H 'Sec-Fetch-User: ?1' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' ``` Perhaps it's a combination of UA and other headers. I'd like to investigate further before merging a fix. CC @tellyworth
|
I can't duplicate this with the provided curl commands, my curl doesn't support the I'd be curious as to what the HTTP response code from api.wordpress.org is, as it should be returning a HTTP error code or output that can be used to figure it out. |
|
Just noting, that the URL being requested, does expose a |
#932 suggests it wasn't just the UA. This leads me to think it could also be an IP rate limit restriction too. I'd be tempted to change the UA sent to be the WordPress UA, which might help.. |
adamziel
added a commit
that referenced
this issue
Jan 15, 2024
Sends HTTP requests directly to api.wordpress.org instead of proxying them. For #916 while looking at the plugin/theme info, I didn't see any reason for them to be proxied, as the endpoints being used there supported CORS requests. While testing however, I found a number of endpoints that were in use that did not have CORS headers, and as a result, I've added them: - [x] POST /plugins/update-check/1.1/ - [x] POST /themes/update-check/1.1/ - [x] POST /core/browse-happy/1.1/ - [x] GET /core/serve-happy/1.0/ - [x] POST /core/version-check/1.7/ For some reason, while `/core/version-check/1.7/` has CORS headers (already) it's still performing an preflight (OPTIONS) request which fails. I'm not sure why that's happening. I've had to adjust the handling for POST requests as well, as fetch() requires `Content-Type: application/x-www-form-urlencoded` to be set, which is just assumed/set by PHP. I'm pretty sure there's a nicer way to handle the `data.headers` being an array, but this worked for me. ## What problem is it solving? I hope this resolves #916 by removing the need to proxy it, avoiding any rate limits ## How is the problem addressed? See above ## Testing Instructions Unsure --------- Co-authored-by: Adam Zieliński <adam@adamziel.com>
|
Hey @tellyworth, did #933 do the trick? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've started getting this error on the plugin/theme install screens when trying to use https://playground.wordpress.net/?networking=yes
TL;DR: it only happens when the request to plugin-proxy.php uses a Firefox User-Agent string.
Detail:
Investigating further with browser dev tools, the browser is making a request like this, which receives a 200 response but zero length content:
curl 'https://playground.wordpress.net/plugin-proxy.php?url=https%3A%2F%2Fapi.wordpress.org%2Fplugins%2Finfo%2F1.2%2F%3Faction%3Dquery_plugins%26request%255Bpage%255D%3D1%26request%255Bper_page%255D%3D36%26request%255Blocale%255D%3Den_US%26request%255Bbrowse%255D%3Dpopular%26request%255Bwp_version%255D%3D6.4' --compressed -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H 'Accept-Language: en,en-US;q=0.5' -H 'Accept-Encoding: gzip, deflate, br' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' -H 'Sec-Fetch-Dest: document' -H 'Sec-Fetch-Mode: navigate' -H 'Sec-Fetch-Site: none' -H 'Sec-Fetch-User: ?1' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'(Request is from firefox, copied as CURL for debugging)
If I run that curl it does indeed return a zero (or 1-byte) length response:
Through trial and error, it seems that deleting the UA string from the CURL request results in the expected json response:
curl 'https://playground.wordpress.net/plugin-proxy.php?url=https%3A%2F%2Fapi.wordpress.org%2Fplugins%2Finfo%2F1.2%2F%3Faction%3Dquery_plugins%26request%255Bpage%255D%3D1%26request%255Bper_page%255D%3D36%26request%255Blocale%255D%3Den_US%26request%255Bbrowse%255D%3Dpopular%26request%255Bwp_version%255D%3D6.4' --compressed -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H 'Accept-Language: en,en-US;q=0.5' -H 'Accept-Encoding: gzip, deflate' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' -H 'Sec-Fetch-Dest: document' -H 'Sec-Fetch-Mode: navigate' -H 'Sec-Fetch-Site: none' -H 'Sec-Fetch-User: ?1' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'(note: I also removed
brfrom the accept-encoding string because my copy of curl doesn't handle it, but that`s not the trigger - it's the UA string)I'm fairly sure this only started happening recently (a few days or less?).
The text was updated successfully, but these errors were encountered: