Send WordPress API requests directly. #933
Conversation
…' header to form-urlencoded, which is not usually specified in PHP.
Ahh.. because we're sending custom headers, which is not supported by CORS without a preflight request. Even if I allow those headers on the API endpoint, because we don't support As a hacky workaround, the fetch code could just only use cors-whitelisted headers to remove the need for the preflight.. I think that would be acceptable.. Otherwise just skipping those wp_* headers would probably be worthwhile (which the next commit has done) |
…doesn't support CORS preflight requests
|
Thank you @dd32! This looks solid. I took the liberty of fixing the lint errors and adjusting the code slightly to make the linter happy and address what you said about the arrays here, and I'd love to merge this as soon as the CI checks pass. Thank you!
|
## Motivation for the change, related issues api.WordPress.org/core/version-check now supports preflight requests, and so we can remove these header deletions that was to resolve CORS issues See #933 for where this was added. ## Testing Instructions (or ideally a Blueprint) The following blueprint should not have a CORS fetch failure in browser console. https://playground.wordpress.net/?mode=seamless#{%22preferredVersions%22:{%22php%22:%228.0%22,%22wp%22:%226.5%22},%22phpExtensionBundles%22:[%22kitchen-sink%22],%22features%22:{%22networking%22:true},%22landingPage%22:%22/wp-admin/update-core.php%22,%22steps%22:[{%22step%22:%22login%22,%22username%22:%22admin%22,%22password%22:%22password%22}]}
## Motivation for the change, related issues api.WordPress.org/core/version-check now supports preflight requests, and so we can remove these header deletions that was to resolve CORS issues See #933 for where this was added. ## Testing Instructions (or ideally a Blueprint) The following blueprint should not have a CORS fetch failure in browser console. https://playground.wordpress.net/?mode=seamless#{%22preferredVersions%22:{%22php%22:%228.0%22,%22wp%22:%226.5%22},%22phpExtensionBundles%22:[%22kitchen-sink%22],%22features%22:{%22networking%22:true},%22landingPage%22:%22/wp-admin/update-core.php%22,%22steps%22:[{%22step%22:%22login%22,%22username%22:%22admin%22,%22password%22:%22password%22}]}
What is this PR doing?
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:
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-urlencodedto be set, which is just assumed/set by PHP.I'm pretty sure there's a nicer way to handle the
data.headersbeing 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