-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore CORS support to CORS proxy #2023
Conversation
*/ | ||
function should_respond_with_cors_headers($host, $origin) { | ||
if ( | ||
$host !== 'playground.wordpress.net' && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also refuse to serve requests coming from playground.wordpress.net?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adamziel do you mean requests from the current playground.wordpress.net proxy server to the dedicated proxy server?
Maybe it would be good for us to send a custom user agent like WordPressPlaygroundCorsProxy
. We could deny all requests with the WordPressPlaygroundCorsProxy
user agent. And it would probably be good to be as forthright as possible with the target servers about the nature of our requests.
Maybe we can make this a configurable header and only set it for the proxy deployed to WP cloud. That way, folks deploying their own instances of the proxy (which won't have most of the defensive meaures) won't send that user agent by default.
Either way, I think that can come as a separate PR.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant making sure we can't request https://playground.wordpress.net/cors-proxy.php
– mu assumption was that the script would still be colocated with the website deployment, which may not be true at all.
Maybe it would be good for us to send a custom user agent like WordPressPlaygroundCorsProxy.
My worry is that it would likely trigger security mechanisms on more than few servers and, e.g., filter out our IP or display a ddos protection screen.
d6c750e
to
e3b9882
Compare
e3b9882
to
7f8e91e
Compare
…ting" This reverts commit 7f8e91e.
… for testing"" This reverts commit 734b8e1.
…y server for testing""" This reverts commit 13e5ee1.
Motivation for the change, related issues
We want to move the CORS proxy to a separate host from playground.wordpress.net. In order to continue using the proxy from playground.wordpress.net, the CORS proxy needs to support cross-origin requests to itself.
Implementation details
This PR updates the CORS proxy to again respond with CORS-related headers for supported origins. Currently, supported origins are "https://playground.wordpress.net" and local origins based on "127.0.0.1" and "localhost".
Testing Instructions (or ideally a Blueprint)