f1outsourcing
Forum Replies Created
-
Hmmm, the upgrade from 5.5.3 to 5.6 does 3233 unnecessary chmod’s, however commenting this code out, only saves around 10 seconds on the upgrade. I thought it would be more.
I think you are on the right track by switching default behaviour.
The goal is to log the ip address from where traffic is originating.
We also want to give an admin correct information. For me having no information or less, is better than having incorrect information.
So my guess the remote_addr would be ok to use in 90% of the use cases. You can
- guarantee
that traffic was coming from this ip. It really doesn’t matter if it is a proxy or not, a good anonymous proxy server setup is not going to reveal client data anyway.
The further handling of proxies is an individual approach, it cannot hurt testing on the existence xforwarded or other variables, and report those to the admin as well. For ‘normal’ proxies some are specifically being set to identify the client. They will need this ip and the timestamp to trace the user.
(I cannot exactly remember how we encountered this here. But if this is linked to blocking host access. I guess it would easy to create a script and start blocking out ip ranges.)
How is this related? You are suggesting a temporary workaround? Or are you illustrating the failing in their good logical reasoning? Because that is what it is. Using a less secure variable above a more secure variable, instead of using the more secure variable and then fallback to a lesser one.
Otherwise you would have the same misconception as developers. You should start with, everything the client is sending is not to be trusted and thus not to be used.
If you don’t get this as a developer on ‘security’, you should stop coding and start baking pancakes.
Furthermore afaik the REMOTE_ADDR can contain an array of ips in case of a proxy being used. (But it is not my job to know these specifics, because i am not developing this security plugin)