Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.0.0-b5
-
Fix Version/s: 4.5.0-b1
-
Component/s: Staff Interface
-
Labels:None
Description
Blesta logs the IP addresses for user logins, sends new order IP addresses to Maxmind (if enabled in the order plugin) for fraud checks, and uses IP addresses for various GeoIP features.
When Blesta is used under a load balanced environment, $_SERVER['REMOTE_ADDR']; will report the load balancer's IP address and not that of the client. This creates a problem in that Blesta is unaware of the clients actual IP address. (By client, I'm referring to the browser client. This affects both Clients and Staff within Blesta)
If the x-forwarded-for header exists, which is or can be set by a load balancer, we should use this instead everywhere we utilize the client's IP address. See https://www.chriswiegman.com/2014/05/getting-correct-ip-address-php/ for more information on getting the right IP address in such a situation.
Issue Links
Activity
Something like that could work, but the language may need to be updated. Is there no other reason to use the x-forwaded-for header other than when behind a load balancer?
Tyson Phillips (Inactive)
added a comment - Something like that could work, but the language may need to be updated. Is there no other reason to use the x-forwaded-for header other than when behind a load balancer? How about a system setting under Settings > System > General > Basic Setup that says something like:
[x] My installation is behind a load balancer
? Tooltip "If checked, Blesta will look for an x-forwarded-for header when evaluating IP addresses for logging, GeoIP, fraud detection, and other purposes."
Paul Phillips
added a comment - How about a system setting under Settings > System > General > Basic Setup that says something like:
[x] My installation is behind a load balancer
? Tooltip "If checked, Blesta will look for an x-forwarded-for header when evaluating IP addresses for logging, GeoIP, fraud detection, and other purposes." This depends on the user's environment, but since the x-forwarded-for header can be easily spoofed, it should only be checked if explicitly set to be checked by an admin with knowledge of the proxy. So we can continue to check the remote address header for the IP address, and use the x-forwarded-for IP address in place of it if configured to do so. And also fallback to the remote address if the x-forwaded-for address is not available or unknown.
Tyson Phillips (Inactive)
added a comment - This depends on the user's environment, but since the x-forwarded-for header can be easily spoofed, it should only be checked if explicitly set to be checked by an admin with knowledge of the proxy. So we can continue to check the remote address header for the IP address, and use the x-forwarded-for IP address in place of it if configured to do so. And also fallback to the remote address if the x-forwaded-for address is not available or unknown. 
HTTP Proxy or load balancer, so perhaps we should list those 2. Load balancer will be the most common, and it is technically an HTTP Proxy. I got this from https://en.wikipedia.org/wiki/X-Forwarded-For while looking to see if there are any other reasons an x-forwarded-for header would be passed through.. proxy & load balancer pretty much sum it up.