Is this possible? Changing the REMOTE_ADDR of a visitor?

[SneakyDave]

I thought I'd start out simple to see if I could create a small add-on for myself and other Cloudflare users.

I'm just starting out with xF add-ons, but I'm familiar with PHP and MVC frameworks.

This add-on would simply replace the $_SERVER['REMOTE_ADDR'] (Cloudflare IP) with $_SERVER['HTTP_CF_CONNECTING_IP'] (true visitor IP) if the HTTP_CF_CONNECTING_IP was set.

Right now, the way I do this, is to put this code in the config.php file, which is an ugly brute force option. So I thought there'd be a way to do this with a code event listener.

Running through the code and the event listeners, I thought a good place to do this re-assignment would be in visitor_setup, but after doing a little more digging, its obvious that the REMOTE_ADDR is used in the Session class. I would need to do this re-assignment prior to that.

Going through debug, it doesn't look like there's anything that fires for the Session class, or I'm just not good at trying to find out where these things fire.

Am I correct in going down the road of using a code event listener? Am I correct in assuming that beings that I'm focusing on the Session class, there aren't any code event listeners that I can use?

Could I possibly extend the FrontController or AutoLoader to do this work?

I'm pretty thick skinned, so please call me an idiot if I've completely gone off the rails on how this can be accomplished.

Thanks in advance.

 

[Kent]

You can't rely on HTTP_CF_CONNECTING_IP being set to tell if the site is being accessed from CloudFlare, because anyone can send that header. You need to check the origin IPs against the ones CloudFlare provides.
https://www.cloudflare.com/ips

However, this is a job better suited for the web server itself and should be done there if possible.

 

[Mike Edge]

Why not just add to index.php



Right under <?php

 

[SneakyDave]

I already have it in config.php. I was going to try to create an add-on for it to files don't need to be edited. Of course, config.php isn't normally changed on upgrades, but I wanted something hopefully simple to create an add-on for.

I got the idea to use the HTTP_CF_CONNECTING_IP from Cloudflare, because there doesn't seem to be a good solution for it for nginx, unless you want to recompile it with that support. I wanted to avoid that. I agree if there was a simpler web host solution, I'd use it.

On the subject of changing HTTP_CF_CONNECTING_IP, can't a nefarious sort change the REMOTE_ADDR also, or are those $_SERVER parms protected?

I guess a better way would be to see if HTTP_CF_CONNECTING_IP is set, and if the REMOTE_ADDR is one of those Cloudflare IP's, then the HTTP_CF_CONNECTING_IP could be trusted as the visitor IP.

Edited to add: I was checking the Wordpress official Cloudflare plug in, and the above way it how they do it, seeing if HTTP_CF_CONNECTING_IP is set, validating the REMOTE_ADDR against Cloudflare's IPs, and then reassigning the REMOTE_ADDR.

It's a PITA because it has to be updated everytime they update their IP list.

It seems a front_controller_pre_route and/or front_controller_pre_dispatch might be a spot for this work. I'll see how much of a bad idea it is.

Thanks for the input.

 

[Kent]

I got the idea to use the HTTP_CF_CONNECTING_IP from Cloudflare, because there doesn't seem to be a good solution for it for nginx, unless you want to recompile it with that support. I wanted to avoid that. I agree if there was a simpler web host solution, I'd use it.

HttpRealipModule. Try using dotdeb or another repository for your flavour... assuming you're on Linux.

On the subject of changing HTTP_CF_CONNECTING_IP, can't a nefarious sort change the REMOTE_ADDR also, or are those $_SERVER parms protected?

No, because REMOTE_ADDR isn't a header. It's a param passed to PHP by the web server itself. Headers are prefixed with HTTP_.

I guess a better way would be to see if HTTP_CF_CONNECTING_IP is set, and if the REMOTE_ADDR is one of those Cloudflare IP's, then the HTTP_CF_CONNECTING_IP could be trusted as the visitor IP.

That's correct, but if at all possible the web server is still a better place for this.