Skip to content
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

Merged
merged 7 commits into from
Dec 4, 2024

Conversation

brandonpayton
Copy link
Member

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)

  • Once Add deploy workflow for standalone CORS proxy #2022 is merged, deploy this branch to the dedicated CORS proxy host.
  • Create a Blueprint that uses the dedicated CORS proxy host.
  • Confirm the Blueprint works with playground.wordpress.net.
  • Confirm the Blueprint works with the local dev server.

*/
function should_respond_with_cors_headers($host, $origin) {
if (
$host !== 'playground.wordpress.net' &&
Copy link
Collaborator

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?

Copy link
Member Author

@brandonpayton brandonpayton Dec 4, 2024

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?

Copy link
Collaborator

@adamziel adamziel Dec 4, 2024

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.

@brandonpayton brandonpayton force-pushed the restore-cors-support-to-cors-proxy branch from d6c750e to e3b9882 Compare December 4, 2024 03:12
@brandonpayton brandonpayton had a problem deploying to playground-wordpress-net-wp-cloud December 4, 2024 03:18 — with GitHub Actions Failure
@brandonpayton brandonpayton had a problem deploying to playground-wordpress-net-wp-cloud December 4, 2024 03:20 — with GitHub Actions Failure
@brandonpayton brandonpayton force-pushed the restore-cors-support-to-cors-proxy branch from e3b9882 to 7f8e91e Compare December 4, 2024 03:23
@brandonpayton brandonpayton temporarily deployed to playground-wordpress-net-wp-cloud December 4, 2024 03:30 — with GitHub Actions Inactive
@brandonpayton brandonpayton temporarily deployed to playground-wordpress-net-wp-cloud December 4, 2024 03:51 — with GitHub Actions Inactive
@brandonpayton brandonpayton marked this pull request as ready for review December 4, 2024 03:56
@brandonpayton brandonpayton temporarily deployed to playground-wordpress-net-wp-cloud December 4, 2024 04:03 — with GitHub Actions Inactive
@brandonpayton brandonpayton merged commit f77ea88 into trunk Dec 4, 2024
6 checks passed
@brandonpayton brandonpayton deleted the restore-cors-support-to-cors-proxy branch December 4, 2024 04:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants