Allow build and preview webhooks to be called in 'private' networks #189
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* only override preview link when not doing gql requests * remove attempt to grab existing manifest id's. this results in outdated id's * Update CHANGELOG.md
This is needed due to 'safe' variant preventing calls to private IP addresses. This does not compromise security, webhook URLs are not dynamic and are controlled by WordPress admins.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes the problem of build/preview webhook being silently ignored when its host resolves to a private IP address. The problem originates from
ActionMonitor::trigger_dispatchcallingwp_safe_remote_postwhich in turn useswp_http_validate_url.wp_http_validate_urldeems private IP addresses invalid.Currently it's impossible to to call a webhook in a local network. The same applies to Docker which uses private IP addressing.
Changing
wp_safe_remote_postto its unsafe variant does not compromise security in this case, because: