Fix Cloudflare IP geolocation using proxy IP instead of visitor's real IP#152
Merged
parhumm merged 9 commits intodevelopmentfrom Mar 12, 2026
Merged
Fix Cloudflare IP geolocation using proxy IP instead of visitor's real IP#152parhumm merged 9 commits intodevelopmentfrom
parhumm merged 9 commits intodevelopmentfrom
Conversation
…l IP - Add HTTP_CF_CONNECTING_IP to proxy header list in Utils::getRemoteIp() - Fix break scope (break → break 2) so first matching header wins - Wire Cloudflare geolocation provider into tracking pipeline via geolocation_provider setting (was hardcoded to maxmind/dbip) - Fix consent-upgrade branch to use other_ip priority (was using REMOTE_ADDR directly) and same CF-Ray-gated override - Extract resolveGeoProvider() helper for DRY provider resolution - Gate CF-Connecting-IP override behind CF-Ray presence check to prevent header spoofing on non-Cloudflare requests Closes #150
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR adds Cloudflare support to IP detection and geolocation tracking. It prioritizes the HTTP_CF_CONNECTING_IP header across multiple components to ensure the real visitor IP is captured instead of Cloudflare's proxy IP, introduces a new utility method for CF IP validation, updates E2E test timing behavior, and removes obsolete testing documentation. Changes
Sequence DiagramsequenceDiagram
participant Client as HTTP Client
participant Tracker as Tracker.process()
participant Utils as Utils.getRemoteIp()
participant Processor as Processor
participant GeoService as GeoService
participant Geo as Geolocation Provider
Client->>Tracker: Request with HTTP_CF_CONNECTING_IP
Tracker->>Utils: Extract remote IP
Note over Utils: Priority: CF_CONNECTING_IP → X-FORWARDED-FOR → REMOTE_ADDR
Utils->>Utils: Validate CF IP format
Utils-->>Tracker: Return IP array with CF IP
Tracker->>Processor: Call with CF IP (if detected)
Processor->>GeoService: Request geolocation for real IP
GeoService->>Geo: Lookup coordinates and country
Geo-->>GeoService: Real visitor location (not proxy)
GeoService-->>Processor: Geolocation result
Processor-->>Tracker: Update tracking data
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/Tracker/Utils.php (1)
133-145:⚠️ Potential issue | 🟠 MajorCF-Connecting-IP header accepted without verifying request came through Cloudflare.
Adding
HTTP_CF_CONNECTING_IPto the header list without checking forHTTP_CF_RAYallows header spoofing on non-Cloudflare requests. An attacker can inject a fakeCF-Connecting-IPheader to:
- Bypass IP-based blacklisting (checked at Processor.php lines 51-66 before your CF-RAY gated override)
- Corrupt analytics data with false IPs
The PR description mentions gating CF-Connecting-IP behind CF-RAY, but that's only implemented in
Processor.phpfor geolocation—not here whereother_ipis first assigned.🔒 Proposed fix: Gate CF-Connecting-IP check behind CF-RAY verification
public static function getRemoteIp() { $ipArray = ['', '']; if (!empty($_SERVER['REMOTE_ADDR']) && false !== filter_var($_SERVER['REMOTE_ADDR'], FILTER_VALIDATE_IP)) { $ipArray[0] = sanitize_text_field(wp_unslash($_SERVER['REMOTE_ADDR'])); } - $originatingIpHeaders = ['HTTP_X_FORWARDED_FOR', 'HTTP_CF_CONNECTING_IP', 'HTTP_X_FORWARDED', 'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED', 'REMOTE_ADDR', 'HTTP_CLIENT_IP', 'HTTP_X_CLUSTER_CLIENT_IP', 'HTTP_X_REAL_IP', 'HTTP_INCAP_CLIENT_IP']; + // Cloudflare: only trust CF-Connecting-IP when CF-Ray header confirms request came through CF + $cfVerified = !empty($_SERVER['HTTP_CF_RAY']); + $originatingIpHeaders = ['HTTP_X_FORWARDED_FOR', 'HTTP_X_FORWARDED', 'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED', 'REMOTE_ADDR', 'HTTP_CLIENT_IP', 'HTTP_X_CLUSTER_CLIENT_IP', 'HTTP_X_REAL_IP', 'HTTP_INCAP_CLIENT_IP']; + if ($cfVerified) { + // Prepend CF-Connecting-IP when verified through Cloudflare + array_unshift($originatingIpHeaders, 'HTTP_CF_CONNECTING_IP'); + } foreach ($originatingIpHeaders as $header) {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/Tracker/Utils.php` around lines 133 - 145, The CF-Connecting-IP header is being accepted unconditionally in Utils.php which allows header spoofing; update the loop that iterates $originatingIpHeaders in the code that assigns $ipArray[1] to skip processing 'HTTP_CF_CONNECTING_IP' unless the request includes a verified Cloudflare indicator (check for non-empty $_SERVER['HTTP_CF_RAY'] before using 'HTTP_CF_CONNECTING_IP'). Concretely, inside the foreach over $originatingIpHeaders (the block that computes $headerValue and sets $ipArray[1]), add a guard that if $header === 'HTTP_CF_CONNECTING_IP' and empty($_SERVER['HTTP_CF_RAY']) then continue to the next header so CF-Connecting-IP is only considered when CF-RAY is present.
🧹 Nitpick comments (1)
src/Tracker/Processor.php (1)
514-530: Consider extracting CF-aware IP selection to a helper.The IP selection logic (prefer
other_ip, then check CF-Connecting-IP when CF-Ray present) is duplicated between lines 69-79 and here. A small helper would reduce duplication.♻️ Optional: Extract helper method
/** * Get the best IP for geolocation, preferring CF-Connecting-IP when verified. * * `@param` string $ip Primary IP (REMOTE_ADDR) * `@param` string $otherIp Proxy-detected IP * `@return` string IP address to use for geolocation */ private static function getGeoIp($ip, $otherIp = '') { $geoIp = !empty($otherIp) ? $otherIp : $ip; if (!empty($_SERVER['HTTP_CF_RAY']) && !empty($_SERVER['HTTP_CF_CONNECTING_IP'])) { $cfIp = filter_var(sanitize_text_field(wp_unslash($_SERVER['HTTP_CF_CONNECTING_IP'])), FILTER_VALIDATE_IP); if ($cfIp) { $geoIp = $cfIp; } } return $geoIp; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/Tracker/Processor.php` around lines 514 - 530, Duplicate CF-aware IP selection is used in Processor::resolveGeoProvider branch and the main tracking branch; extract it into a private static helper (e.g., getGeoIp) that accepts ($ip, $otherIp = '') and implements the current logic: prefer $otherIp if set, then if $_SERVER['HTTP_CF_RAY'] and $_SERVER['HTTP_CF_CONNECTING_IP'] exist validate/filter the CF IP using sanitize_text_field + wp_unslash + FILTER_VALIDATE_IP and return it when valid, otherwise return the chosen IP; replace the inline selection in both locations with a call to Processor::getGeoIp(realIp, realOtherIp) and ensure the new method is declared in the same class (private static) so GeolocationService instantiation still receives the correct $geoIp.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@src/Tracker/Utils.php`:
- Around line 133-145: The CF-Connecting-IP header is being accepted
unconditionally in Utils.php which allows header spoofing; update the loop that
iterates $originatingIpHeaders in the code that assigns $ipArray[1] to skip
processing 'HTTP_CF_CONNECTING_IP' unless the request includes a verified
Cloudflare indicator (check for non-empty $_SERVER['HTTP_CF_RAY'] before using
'HTTP_CF_CONNECTING_IP'). Concretely, inside the foreach over
$originatingIpHeaders (the block that computes $headerValue and sets
$ipArray[1]), add a guard that if $header === 'HTTP_CF_CONNECTING_IP' and
empty($_SERVER['HTTP_CF_RAY']) then continue to the next header so
CF-Connecting-IP is only considered when CF-RAY is present.
---
Nitpick comments:
In `@src/Tracker/Processor.php`:
- Around line 514-530: Duplicate CF-aware IP selection is used in
Processor::resolveGeoProvider branch and the main tracking branch; extract it
into a private static helper (e.g., getGeoIp) that accepts ($ip, $otherIp = '')
and implements the current logic: prefer $otherIp if set, then if
$_SERVER['HTTP_CF_RAY'] and $_SERVER['HTTP_CF_CONNECTING_IP'] exist
validate/filter the CF IP using sanitize_text_field + wp_unslash +
FILTER_VALIDATE_IP and return it when valid, otherwise return the chosen IP;
replace the inline selection in both locations with a call to
Processor::getGeoIp(realIp, realOtherIp) and ensure the new method is declared
in the same class (private static) so GeolocationService instantiation still
receives the correct $geoIp.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: a0563f4b-b989-4e85-810b-34a0ac84388a
📒 Files selected for processing (2)
src/Tracker/Processor.phpsrc/Tracker/Utils.php
Contributor
Author
Manual QA ChecklistPrerequisites: Cloudflare Setup (Step-by-Step)
1. Add your site to Cloudflare (free plan works) 2. Enable Cloudflare proxy (orange cloud) 3. (Optional) Install Cloudflare WordPress plugin wp plugin install cloudflare --activate
4. Verify Cloudflare is active # From your local machine, curl your site and check for CF headers:
curl -sI https://yourdomain.com | grep -i "cf-ray\|server: cloudflare"
# You should see:
# cf-ray: <hex>-<datacenter>
# server: cloudflare5. Configure WP Slimstat geolocation provider Test ScenariosScenario 1: Cloudflare + Cloudflare geo provider
Scenario 2: Cloudflare + MaxMind/DB-IP provider
Scenario 3: Non-Cloudflare setup (direct / standard proxy)
Scenario 4: CF-Connecting-IP spoofing prevention
Scenario 5: Consent-upgrade flow (if GDPR consent plugin active)
Scenario 6:
|
…e with development Merges v5.4.2 release, GeoIP infinite-loop fix, visit ID improvements, and upgrade safety tests. Resolves conflict in Processor.php by adopting the development API (wp_slimstat::resolve_geolocation_provider) while preserving Cloudflare CF-Connecting-IP header logic from this branch.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/Tracker/Processor.php (1)
518-531: Please centralize GeoIP source resolution for both flows.This branch now reimplements the same Cloudflare/
other_ipselection used earlier inprocess(). Keeping two copies of that trust logic makes future fixes easy to miss in one path, especially around consent upgrades.♻️ Possible extraction
- // Use same IP priority as main tracking branch: - // prefer real client IP from proxy headers over REMOTE_ADDR - $geoIp = !empty($realOtherIp) ? $realOtherIp : $realIp; - - // Cloudflare: prefer CF-Connecting-IP when verified via CF-Ray - if (!empty($_SERVER['HTTP_CF_RAY']) && !empty($_SERVER['HTTP_CF_CONNECTING_IP'])) { - $cfIp = filter_var(sanitize_text_field(wp_unslash($_SERVER['HTTP_CF_CONNECTING_IP'])), FILTER_VALIDATE_IP); - if ($cfIp) { - $geoIp = $cfIp; - } - } + $geoIp = self::resolveGeoIp($realIp, $realOtherIp);private static function resolveGeoIp(string $ip, string $otherIp = ''): string { $geoIp = '' !== $otherIp ? $otherIp : $ip; // Keep the Cloudflare trust check here. return $geoIp; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/Tracker/Processor.php` around lines 518 - 531, Extract the duplicated GeoIP source resolution into a single private static method on Tracker\Processor (e.g., private static function resolveGeoIp(string $ip, string $otherIp = ''): string) that implements the same precedence (prefer $otherIp when present, then prefer Cloudflare's HTTP_CF_CONNECTING_IP if HTTP_CF_RAY is present) and performs the same sanitization/filtering (sanitize_text_field + wp_unslash + FILTER_VALIDATE_IP) used in the duplicated block; then replace the in-place logic around $geoIp, $cfIp and the Cloudflare checks with a call to Processor::resolveGeoIp($realIp, $realOtherIp) before creating GeolocationService and calling locate to ensure both processing flows share the single trusted resolution function.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/Tracker/Processor.php`:
- Around line 70-78: The geolocation path in Processor.php currently trusts
HTTP_CF_CONNECTING_IP (setting $originalIpForGeo) if HTTP_CF_RAY is present, but
Utils.php earlier promotes HTTP_CF_CONNECTING_IP into other_ip before any
Cloudflare verification, allowing header spoofing; change the logic so the trust
decision is enforced where other_ip is derived (i.e., in the Utils function that
promotes HTTP_CF_CONNECTING_IP) or refuse to use HTTP_CF_CONNECTING_IP in
Processor:: (the block that sets $originalIpForGeo) unless the proxy is
explicitly trusted: only accept CF headers when the request has been validated
as coming through Cloudflare (e.g., verify CF-Ray against a whitelist of
Cloudflare edge IPs or use the same trusted-proxy flag used when computing
other_ip), and ensure $originalIpForGeo falls back to REMOTE_ADDR or the
already-trusted other_ip rather than any raw HTTP_CF_CONNECTING_IP value.
---
Nitpick comments:
In `@src/Tracker/Processor.php`:
- Around line 518-531: Extract the duplicated GeoIP source resolution into a
single private static method on Tracker\Processor (e.g., private static function
resolveGeoIp(string $ip, string $otherIp = ''): string) that implements the same
precedence (prefer $otherIp when present, then prefer Cloudflare's
HTTP_CF_CONNECTING_IP if HTTP_CF_RAY is present) and performs the same
sanitization/filtering (sanitize_text_field + wp_unslash + FILTER_VALIDATE_IP)
used in the duplicated block; then replace the in-place logic around $geoIp,
$cfIp and the Cloudflare checks with a call to Processor::resolveGeoIp($realIp,
$realOtherIp) before creating GeolocationService and calling locate to ensure
both processing flows share the single trusted resolution function.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 64b15de4-e5cd-493e-9e97-8c44d6ca74c6
📒 Files selected for processing (1)
src/Tracker/Processor.php
All functional tests pass: geolocation-provider (8/8), upgrade-data-integrity (7/7), upgrade-safety (6/6), visit-id-performance (8/8). Three geoip-ajax-loop tests fail due to navigation timeout under local system load — pre-existing flakiness unrelated to Cloudflare IP fix or development merge changes.
…imeouts PHP: - Add Utils::getCfClientIp() — single source of truth for CF-Connecting-IP extraction and validation (CF-Ray presence check + filter_var) - Replace two duplicate CF detection blocks in Processor.php with helper calls - Move HTTP_CF_CONNECTING_IP to first position in all three originatingIpHeaders arrays (Utils.php, Tracker.php, GeoService.php) — CF header is Cloudflare-verified and not client-spoofable, so it takes priority over HTTP_X_FORWARDED_FOR E2E: - geoip-ajax-loop: reduce Test 2 to 2 pages (2×30 s < 90 s budget on slow local servers), add waitUntil:domcontentloaded to Tests 2/4/6, raise Test 6 timeout to 90 s - visit-id-performance: add waitUntil:domcontentloaded to concurrent navigations, raise concurrent assertion threshold to 90 s and test timeout to 90 s Result: 35/35 pass
…utputs/qa/wp-slimstat-e2e/
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/Services/GeoService.php (1)
90-99:⚠️ Potential issue | 🟡 MinorMissing input sanitization and CF-Ray validation.
Two issues in the
getUserIP()fallback path:
Sanitization gap: Lines 93-95 return
$ipdirectly withoutsanitize_text_field(wp_unslash(...)), unlikegetRemoteIp()inUtils.phpwhich properly sanitizes.Inconsistent CF-Ray check:
Utils::getCfClientIp()validatesHTTP_CF_RAYpresence before trustingHTTP_CF_CONNECTING_IPto prevent spoofing. This method trusts the CF header unconditionally.While the risk is lower (used only for geolocation lookup), consider aligning with the validated pattern in
Utils.php.🛡️ Proposed fix for sanitization and consistency
public function getUserIP() { if (!empty($_SERVER['REMOTE_ADDR']) && false !== filter_var($_SERVER['REMOTE_ADDR'], FILTER_VALIDATE_IP)) { return sanitize_text_field(wp_unslash($_SERVER['REMOTE_ADDR'])); } - $originating_ip_headers = ['HTTP_CF_CONNECTING_IP', 'HTTP_X_FORWARDED_FOR', 'HTTP_X_FORWARDED', 'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED', 'REMOTE_ADDR', 'HTTP_CLIENT_IP', 'HTTP_X_CLUSTER_CLIENT_IP', 'HTTP_X_REAL_IP', 'HTTP_INCAP_CLIENT_IP']; + // Prefer validated CF IP when available + $cfIp = \SlimStat\Tracker\Utils::getCfClientIp(); + if (null !== $cfIp) { + return $cfIp; + } + + $originating_ip_headers = ['HTTP_X_FORWARDED_FOR', 'HTTP_X_FORWARDED', 'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED', 'REMOTE_ADDR', 'HTTP_CLIENT_IP', 'HTTP_X_CLUSTER_CLIENT_IP', 'HTTP_X_REAL_IP', 'HTTP_INCAP_CLIENT_IP']; foreach ($originating_ip_headers as $a_header) { if (!empty($_SERVER[$a_header])) { - foreach (explode(',', $_SERVER[$a_header]) as $ip) { + $header_value = sanitize_text_field(wp_unslash($_SERVER[$a_header])); + foreach (explode(',', $header_value) as $ip) { + $ip = trim($ip); if (false !== filter_var($ip, FILTER_VALIDATE_IP)) { return $ip; } } } } return false; }As per coding guidelines: "Sanitize all inputs using
sanitize_text_field(),intval(),sanitize_email(),sanitize_key(),wp_unslash(), andesc_url_raw()where relevant."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/Services/GeoService.php` around lines 90 - 99, The getUserIP() fallback currently returns raw $ip and trusts Cloudflare headers unconditionally; update it to mirror Utils::getRemoteIp()/Utils::getCfClientIp() by first checking for a valid CF signal (HTTP_CF_RAY) before trusting HTTP_CF_CONNECTING_IP and by sanitizing any candidate IPs with wp_unslash() and sanitize_text_field() (and still validate with filter_var(FILTER_VALIDATE_IP)) before returning; locate the logic in getUserIP() and replace the direct return of $ip with the sanitized, validated value and add the CF-Ray presence check consistent with Utils::getCfClientIp().
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@src/Services/GeoService.php`:
- Around line 90-99: The getUserIP() fallback currently returns raw $ip and
trusts Cloudflare headers unconditionally; update it to mirror
Utils::getRemoteIp()/Utils::getCfClientIp() by first checking for a valid CF
signal (HTTP_CF_RAY) before trusting HTTP_CF_CONNECTING_IP and by sanitizing any
candidate IPs with wp_unslash() and sanitize_text_field() (and still validate
with filter_var(FILTER_VALIDATE_IP)) before returning; locate the logic in
getUserIP() and replace the direct return of $ip with the sanitized, validated
value and add the CF-Ray presence check consistent with Utils::getCfClientIp().
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 6d8d49b1-efc5-4a22-8e65-e6c10fe108f2
📒 Files selected for processing (6)
src/Services/GeoService.phpsrc/Tracker/Processor.phpsrc/Tracker/Tracker.phpsrc/Tracker/Utils.phptests/e2e/geoip-ajax-loop.spec.tstests/e2e/visit-id-performance.spec.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/Tracker/Processor.php
Contributor
Author
QA Report — merge(development) into fix/150-cloudflare-ip-geolocation
Simple Summary
Merge SummaryMerged
Conflict in
Code Changes (from /simplify review)
Test Results — Final: 35/35 ✅
Analytics Invariants
Verdict: PASS — Core tracking, geolocation, upgrade safety, and visit ID invariants all verified. Branch is ready. |
Three targeted tests proving the Cloudflare IP fix: 1. DB-IP uses CF-Connecting-IP (8.8.8.8→US) when CF-Ray present 2. CF-Connecting-IP ignored without CF-Ray (anti-spoofing) 3. German IP (5.9.49.12→DE) resolves correctly via CF headers
…IP, DRY test setup - Tracker.php: fix break → break 2 (same bug that was fixed in Utils.php) - GeoService.php: add missing sanitize_text_field(wp_unslash()) + trim() - cloudflare-ip-regression.spec.ts: extract shared config to beforeEach, replace waitForTimeout with polling helper, set timeout at describe level
…r arrays The anti-spoofing E2E test proved that including CF-Connecting-IP in the general getRemoteIp() header array bypasses the CF-Ray validation in getCfClientIp(). Without CF-Ray, any client can spoof this header to control their detected IP and geolocation. Fix: remove from all 3 general header arrays (Utils.php, Tracker.php, GeoService.php). The CF-Connecting-IP is now only used via the safe getCfClientIp() path which validates CF-Ray presence.
Contributor
Author
QA Verification Report — PR #152Verdict: PASS — Issue #150 is fixed. All PR-specific tests pass. Test Results (52 tests, 12.2 min)
New Regression Tests (Issue #150 Proof)
Security Fix Found During TestingThe anti-spoofing regression test revealed that HTTP_CF_CONNECTING_IP in the general getRemoteIp() header array bypassed the CF-Ray validation in getCfClientIp(). Without CF-Ray, any client could spoof this header to control their detected IP. Fix (commit 3c87a0c): Removed HTTP_CF_CONNECTING_IP from all 3 general header arrays. CF IP now only flows through the safe getCfClientIp() path which validates CF-Ray presence. Additional Fixes (/simplify)
Commits Added
Pre-existing Failures (unrelated)
Merge StatusMerged development (PRs #174-#179) into branch — zero conflicts. 37 files integrated cleanly. |
6 tasks
Merged
This was referenced Mar 19, 2026
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.
Summary
HTTP_CF_CONNECTING_IPto proxy header list inUtils::getRemoteIp()(same trust level as existing headers, placed afterX-Forwarded-For)break→break 2in IP detection loop so the first matching header wins (general bug: later headers were overwriting earlier, more-trusted ones)geolocation_providersetting (was hardcoded to maxmind/dbip — the admin UI offered Cloudflare but the tracker never used it)other_ip ?: ippriority (was using$realIp/ REMOTE_ADDR directly — a pre-existing bug causing proxy IP geolocation for all proxy setups)HTTP_CF_RAYpresence to prevent spoofing on non-Cloudflare requestsresolveGeoProvider()helper for DRY provider resolution across both branchesTest plan
Closes #150
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Tests
Documentation