I noticed that the return value of the ip_address() function was incorrect.
Steps I used to produce this issue on my dev site (outside of cloudflare):
1. Change the CLOUDFLARE_URL_IPV4_RANGE definition to point to a file I can modify.
2. In the file, add an IP block covering my computer's IP address to the list of Cloudflare ip blocks. (e.g. 192.168.100.0/24 )
3. Using the Modify Headers browser extension for Firefox, I set the "X-Forwarded-For" header.
The value I used for the X-Forwarded-For header is "23.45.67.89,192.168.100.167,103.22.200.10". In this test setup, my computer's IP is 192.168.100.167 (so it shows up in $_SERVER["REMOTE_ADDR"]). My intention was to simulate what would be seen by a production server (REMOTE_ADDR would be Cloudflare's IP). Both 192.168.100.167 and 103.22.200.10 are in the ranges of my custom Cloudflare IP blocks list. 23.45.67.89 is a made-up IP address which I was trying to get the function ip_address() to return.
The returned IP address is 192.168.100.167. Expected result: 23.45.67.89. This affects various parts of Drupal which call the ip_address function including logging with watchdog().
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | cloudflare-ip_detection_fix-2756713-2-D7.patch | 719 bytes | nullkernel |
Comments
Comment #2
nullkernel commentedI have a patch which corrects the result of the testcase I described. The solution is to add the detected cloudflare ip addresses to $conf['reverse_proxy_addresses'].
The way I get a list of Cloudflare IPs is by diffing two arrays. One array contains all IPs in the X-Forwarded-For header and the other contains non cloudflare IPs. Perhaps it would be good to rename the existing variable $good_ips to $non_cloudflare_ips for clarity?
Comment #3
rosk0