-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request ips wrong order when using a load balancer #115
Comments
Hi! To my knowledge, nothing in this package would change that behavior. At the end of the day, this package's responsibility is purely calling I'm guessing you'll get the same when calling the following (which I think the Laravel methods you used just wrap): $request->getClientIp();
$request->getClientIps(); This might be a bug to file upstream in Symfony. The code I'm seeing in public function getClientIp()
{
$ipAddresses = $this->getClientIps();
return $ipAddresses[0];
} |
The cal to public function getClientIps()
{
$ip = $this->server->get('REMOTE_ADDR');
if (!$this->isFromTrustedProxy()) {
return array($ip);
}
return $this->getTrustedValues(self::HEADER_X_FORWARDED_FOR, $ip) ?: array($ip);
} I'm not sure why that's calling |
This behaviour is expected when updating from TrustedProxy v3.3 to v4+, as the meaning of The Symfony
To have |
This is worked perfectly. Thanks a lot.. |
Thanks. I had the same problem with Laravel Vapor. |
This really helped!! It was driving me crazy as the api rating was not working but everything else did |
I think the README needs updating because otherwise this is painful...
|
I’ll redo the readme soon to clear things up.
Hard to find time lately (kids!) but it’s on my radar!
…On Sat, Apr 25, 2020 at 15:12 Kieran ***@***.***> wrote:
I think the README needs updating because otherwise this is painful...
1. The code says ** is deprecated yet the README says to use it
2. As pointed out above ** doesn't do what it says in the README, and
you need to use the workaround mentioned
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#115 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADSDUZS6B73IZZY36IHBMDROM73HANCNFSM4GCUUHPQ>
.
|
I'd be happy to send a PR if you just want to replace |
definitely larger changes in mind! I also need to do directions per version
and make it more clear what versions are included in laravel out of the
box, etc
…On Sun, Apr 26, 2020 at 10:19 Kieran ***@***.***> wrote:
I'd be happy to send a PR if you just want to replace ** with the above
fix :) if you've got larger changes in mind then no worries!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#115 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADSDU5B6DJFNEXOW4MLJJTRORGJLANCNFSM4GCUUHPQ>
.
|
Took a first stab at a simpler/better readme.md but PR's welcome for formatting/explanation changes. |
I did notice that when using the workaround, you don't get anymore the chain of ips but only the client ip. I found it really useful when you have multiple ips in the chain to see what the route was (example, Cloudflare -> CloudFront -> ELB -> EC2, I used to get at least 3 ips when calling "$request->ips()" and now I am only getting 1). Anybody else noticed that? And is there any other workaround to get back the chain of ips? Or should I just use |
Laravel's Incidentally, I imagine this is why If you need all the IPs in the chain for logging/monitoring/curiosity, the basic route would be: $ips = [];
foreach (explode(',', $request->headers->get('X_FORWARDED_FOR')) as $ip) {
$ips[] = trim($ip);
}
$ips[] = $request->server->get('REMOTE_ADDR'); |
This reinstates the behaviour originally present in fideveloper/trustedproxy where setting ** as the value for app.trustedProxies would allow all proxies vs * which would only allow the most recent one in a chain of proxies (as determined by $_SERVER['REMOTE_ADDR']). See fideloper/TrustedProxy@6018dfb for when & why it was originally added. The '**' wildcard was removed in v4 of that package (fideloper/TrustedProxy@1d09591) with no explanation and was never added back in when Laravel merged it into the core in laravel/framework#38295. This causes problems for environments where you have multiple proxies in a chain (i.e. Amazon CloudFront in front of Amazon ELB). These problems are documented in fideloper/TrustedProxy#115 & fideloper/TrustedProxy#107, and spawned fideloper/TrustedProxy#142 & https://github.com/ge-tracker/laravel-vapor-trusted-proxies to resolve them. Ultimately, this commit serves to reintroduce the original behaviour of fideveloper/trustproxies v3 and make it so that you can use `**` as the value for app.trustProxies in order to get the correct client IP address when running Winter on Laravel Vapor.
Hi, I recently upgrade one application from Laravel 5.2 to Laravel 5.7
Before the upgrade I was using this library (v3.3) with the configuration below
After the upgrade, I added the TrustProxies middleware below
The issue I am having might not be related to this, but basically after the upgrade
It seems the order or the ips is inverted, I should be getting first the client ip, then any other ip.
Is this a configuration issue on my side or is there anything else I am missing?
The text was updated successfully, but these errors were encountered: