Repository navigation
fix: false 'behind a proxy' notice on managed hosts, broken notice button; release 2.10.5 - #113
Merged
Merged
Conversation
…isitor The "not blocking: behind a proxy it has not been told about" notice fired on any admin request carrying a forwarding header. Managed hosts (WordPress.com, nginx real_ip, Apache mod_remoteip) rewrite REMOTE_ADDR to the visitor and still pass X-Forwarded-For along, so nearly every install saw the notice, and enforcement was withheld on sites where every visitor already had their own address. maybe_flag_proxy() now uses WebDecoy_Blocker::unresolved_forwarding_header(), which flags only when REMOTE_ADDR is absent from every forwarded address (X-Forwarded-For lists, RFC 7239 Forwarded, ports, brackets, IPv6). The signal is still sampled from an administrator's request only, so a visitor cannot switch enforcement off with a forged header. Stale flags clear on the next admin page load. The notice's "Configure trusted proxies" button (and the monitor-mode button) linked to page=webdecoy-settings, which does not exist; the settings page slug is "webdecoy". It now goes there, anchored to the field.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem
Every new install, including WordPress.com, showed "WebDecoy is not blocking: this site is behind a proxy it has not been told about", and the notice's Configure trusted proxies button led to WordPress's "Sorry, you are not allowed to access this page."
Causes
maybe_flag_proxy()set the flag whenever an admin request carried any forwarding header. Hosts that rewriteREMOTE_ADDRto the visitor (WordPress.com, nginxreal_ip, Apachemod_remoteip) still passX-Forwarded-Foralong. On those hosts every visitor already has their own address, but the plugin withheld enforcement anyway.admin.php?page=webdecoy-settings, which isn't a registered page. The settings page slug iswebdecoy.Fix
WebDecoy_Blocker::unresolved_forwarding_header()flags only whenREMOTE_ADDRis absent from every forwarded address. It parsesX-Forwarded-Forlists, RFC 7239Forwarded: for=, ports, brackets and IPv6, and compares canonical forms.maybe_flag_proxy()uses it.admin.php?page=webdecoy, and the proxy button is anchored to#webdecoy_trusted_proxies.Release
The second commit bumps to 2.10.5 (
webdecoy.php,readme.txt,changelog.txt,cdn-files/plugin-info.json).Testing
tests/ProxyDetectionTest.phpcovers 9 cases: hosts that resolved the address (XFF single and chain, CF,Forwardedwith IPv6 and port, IPv4 with port), unresolved XFF and CF, and a junk header value.php tests/run.php: 205 passed, 0 failed.