I see that the call to $request->setTrustedProxies() provides only 1 argument as seen below:

private function setTrustedProxyIpAddressesToTheCallingIp($request) {
    $request->setTrustedProxies($request->getClientIps());
}

but setTrustedProxies() now requires two arguments: https://github.com/symfony/http-foundation/blob/master/Request.php#L587

Unless I am mistaken, TrustedProxy, as is, is no longer working.

If I try to wget the root folder of my app page, then it will redirect me to the /login page via Laravel's redirect() helper method.

I have a web server behing a load balancer that is the endopoint for SSL. When I open the root url of my app, I get redirected to the /login page if not logged in, an everything works fine and the final result is as expected (I get redirected properly)

But what happens behind the scene is the following:

1. I ask for https://app.workstack.io
2. Load balancer forwards it to the web server that responds with a redirect to HTTP://app.workstack.io/login
3. Request is sent to the Load Balancer that redirects again to HTTPS://app.workstack.io/login
4. Finally the request goes through the web server and I output the login page.

My question is: Is it possible in some way to avoid the extra redirect from http to https? I think it's a similar problem like when using the url() helper, where you need to replace it with secure_url() or it will be output with http instead of https. Is there a way to tell Laravel to use always https by default for all the url generated by its helper methods? (url(), redirect(), etc.)

I copy here the wget of the request so that it get be more clear

wget https://app.workstack.io --2016-06-09 22:08:37-- https://app.workstack.io/ Resolving app.workstack.io (app.workstack.io)... 174.143.185.9 Connecting to app.workstack.io (app.workstack.io)|174.143.185.9|:443... connected. HTTP request sent, awaiting response... 302 Found Location: http://app.workstack.io/login [following] --2016-06-09 22:08:37-- http://app.workstack.io/login Connecting to app.workstack.io (app.workstack.io)|174.143.185.9|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://app.workstack.io/login [following] --2016-06-09 22:08:37-- https://app.workstack.io/login Connecting to app.workstack.io (app.workstack.io)|174.143.185.9|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘index.html.3’

Thanks a lot for this awesome library btw! :)

Our setup has multiple LB IP addresses, first a local one 10.* and then a public one 130.*. Lastly the users IP. This means that TrustedProxy should filter out 10.* and 130.*, but no matter what I do, it only filters out the first IP.

Everything worked correctly in version 3.*, but after upgrading to 4.*, it stopped working. Doesn't TrustedProxy support multiple layers of load balancers anymore?

Our environment is Google Cloud Platform with Laravel 5.6 and PHP 7.1.

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

    'proxies' => '**',
...
    'headers' => [
        (defined('Illuminate\Http\Request::HEADER_FORWARDED') ? Illuminate\Http\Request::HEADER_FORWARDED : 'forwarded') => null,
        Illuminate\Http\Request::HEADER_CLIENT_IP    => 'X_FORWARDED_FOR',
        Illuminate\Http\Request::HEADER_CLIENT_HOST  => null,
        Illuminate\Http\Request::HEADER_CLIENT_PROTO => 'X_FORWARDED_PROTO',
        Illuminate\Http\Request::HEADER_CLIENT_PORT  => 'X_FORWARDED_PORT',
    ]

After the upgrade, I added the TrustProxies middleware below

<?php

namespace App\Http\Middleware;

use Fideloper\Proxy\TrustProxies as Middleware;
use Illuminate\Http\Request;

class TrustProxies extends Middleware
{
    /**
     * The trusted proxies for this application.
     *
     * @var array
     */
    protected $proxies = '**';

    /**
     * The headers that should be used to detect proxies.
     *
     * @var int
     */
    protected $headers = Request::HEADER_X_FORWARDED_AWS_ELB;
}

The issue I am having might not be related to this, but basically after the upgrade

$request->ip() // the ec2 ip
$request->ips() // [ec2 ip, client ip]

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?

Hi,

Prior to 4.0, i could do something like this in config/trustproxy.php :

'headers' => [
    (defined('Illuminate\Http\Request::HEADER_FORWARDED') ? Illuminate\Http\Request::HEADER_FORWARDED : 'forwarded') => 'FORWARDED',
    Illuminate\Http\Request::HEADER_CLIENT_IP    => 'X_FORWARDED_FOR',
    Illuminate\Http\Request::HEADER_CLIENT_HOST  => 'X_FORWARDED_HOST',
    Illuminate\Http\Request::HEADER_CLIENT_PROTO => 'X_FORWARDED_PROTO_CUSTOM',
    Illuminate\Http\Request::HEADER_CLIENT_PORT  => 'X_FORWARDED_PORT_CUSTOM',
]

But with 4.0 i can't find a way to specify custom names for HEADER_CLIENT_PORT and HEADER_CLIENT_PROTO

Does someone know how to deal with this issue ?

thx

I had been up and running with you proxy for about a month now on an AWS box with load balancer and Laravel on backend. After an upgrade (at 3.3 now) now getting an error:

ErrorException in TrustProxies.php line 159:
A non-numeric value encountered
in TrustProxies.php line 159
at HandleExceptions->handleError('2', 'A non-numeric value encountered', '/home/forge/isdb.io/code/Laravel/vendor/fideloper/proxy/src/TrustProxies.php', '159', array('set' => '0', 'key' => 'forwarded')) in /home/forge/isdb.io/code/Laravel/vendor/fideloper/proxy/src/TrustProxies.php line 159
at TrustProxies->Fideloper\Proxy\{closure}('0', 'forwarded')

Scratching my head with no clue whats happening....any help would be appreciated.

Thx

DJK

1. Accept IPs separated by comma.
   • Probably In a project like Laravel you need to add this config to the .env file and array is not supported in .env

TRUSTEDPROXY_PROXIES='192.168.1.1, 192.168.1.2'

'proxies' => env('TRUSTEDPROXY_PROXIES', null),

2. Accept headers as a string.
   • Probably In a project like Laravel you need to add this config to the .env file and you can pass the header you want to use as a string:

TRUSTEDPROXY_HEADERS='HEADER_X_FORWARDED_AWS_ELB'

'headers' => env('TRUSTEDPROXY_HEADERS', 'HEADER_X_FORWARDED_ALL'),

Hello I've just upgraded an app from 5.4.36 to 5.5 (via Laravel Shift, with PHP 7.1.13 on Homestead vagrant box.)

I'm getting this E_WARNING for vendor/fideloper/proxy/src/TrustProxies.php:162, even though to the best of my knowledge I've not configured load balancing etc. at all:

array_keys() expects parameter 1 to be array, integer given

    protected function getTrustedHeaderSet()
    {
        $trustedHeaderNames = $this->getTrustedHeaderNames();
        $headerKeys = array_keys($this->getTrustedHeaderNames());

Composer has fideloper/proxy (3.3.4) (specified as "~3.3")

I can fix it by simply casting to an array with:

$headerKeys = array_keys((array) $this->getTrustedHeaderNames());

Is that adequate? (I know nothing about your package...)

(Thanks)

Hi,

I'm using Elastic Beanstalk (with a load balancer) and Lumen 5.4 - I followed the steps (code included below) however, when calling $request->getClientIp(); I'm still getting the load balancer's IP;

bootstrap/app.php

 $app->middleware([
     // other middleware
     'Fideloper\Proxy\TrustProxies'
 ]);

// other service providers
$app->register(Fideloper\Proxy\TrustedProxyServiceProvider::class);

config/trustedproxy.php

<?php

return [
    'proxies' => [
        '*',
    ],

    // These are defaults already set in the config:
    'headers' => [
        (defined('Illuminate\Http\Request::HEADER_FORWARDED') ? Illuminate\Http\Request::HEADER_FORWARDED : 'forwarded') => null,
        \Illuminate\Http\Request::HEADER_CLIENT_IP    => 'X_FORWARDED_FOR',
        \Illuminate\Http\Request::HEADER_CLIENT_HOST  => null,
        \Illuminate\Http\Request::HEADER_CLIENT_PROTO => 'X_FORWARDED_PROTO',
        \Illuminate\Http\Request::HEADER_CLIENT_PORT  => 'X_FORWARDED_PORT',
    ]
];

What's actually being forwarded;

[HTTP_X_FORWARDED_FOR] => 141.105.x.x (real IP)
[HTTP_X_FORWARDED_PORT] => 80
[HTTP_X_FORWARDED_PROTO] => http

Am I missing something from this configuration?

It would be useful to be able to pass a list of trusted proxies via an environment variable, for example TRUSTED_PROXIES=192.168.0.10,172.10.0.4.

My specific use case is running CachetHQ. They trust CloudFlare's IPs by default, but I need to add my local nginx reverse proxy IP to that list. My only option now is to change that file directly, which isn't ideal.

Although the reason I'd like this is very specific, there're other cases where it would be useful. For example, trusting different proxies in different environments (dev, qa, staging, production).

What do you think?

Hi!

I'm running 2 laravels behind an IBM Load Balancer and i cant get Trustedproxy to work. I've tried all the configs mentioned in previous issues but i cant make it work.

thanks!

Laravel 9 has incorporated this package into the core of Laravel.

See the upgrade guide here: https://laravel.com/docs/9.x/upgrade, search for Trusted Proxies

This could either be an issue with the documentation and comments, or it could be an issue with the way that wildcards are being handled. Because of that, I have only created this as a draft pull request to prompt discussion on the matter and in the hope that either the code or the documentation are fixed.

From the documentation and code comments, I am concluding that the intent of using * as a wildcard is to trust all proxies, however; all it currently appears to do is trust the calling IP address and not every IP in the chain.

For example, if a request goes through the following flow CloudFlare > DigitalOcean > Kubernetes one may end up with the something akin to 123.456.0.1, 172.68.0.1, 104.16.0.1 for the value of $_SERVER['HTTP_X_FORWARDED_FOR'] where 123.456.0.1 is the actual source IP. When using * as a wildcard, this package erroneously returns 104.16.0.1 when calling request()->ip() instead of the expected result.

This pull request addresses this issue and corrects the order of IPs in tests so that they match what's received in real world scenarios. The reversed IP addresses are also an indicator that this is a code issue, that is, assuming that wasn't the intent, and if it was the intent, then that would ideally be handled in a separate code block or perhaps some comments added to indicate so.

Other open issues also mention this, for example, https://github.com/fideloper/TrustedProxy/issues/115 and https://github.com/fideloper/TrustedProxy/issues/107

This PR adds support for custom bitmasks, which are necessary if your load balancer doesn't support all X-Forwarded-* headers and doesn't support the same subset of X-Forwarded-* headers that AWS ELB uses. I personally ran into this while using ngrok via valet share, which doesn't send HEADER_X_FORWARDED_PORT.

This will fix "failed to open required file" When we use this package (with laravel) inside phar archive.

The problem happen because realpath will return the full path when the package no longer exist in disk.

With this pull request the path will be relative and will work inside phar archive.

In this PR, I simply renamed the boot to register, and deleted boot as it is unused for now.

mergeConfigFrom should be called in the register method, it means once the package being registered, its config are ready to use. Then other services can access them safely without caring about the order of application services bootstrap.

This is also mentioned in the official documentation:

To merge the configurations, use the mergeConfigFrom method within your service provider's register method.

publishes is useful only in the console application, and in the console application all services will be booted, so it does not matter putting publishes whether in register or boot method. Some core services also put it in register to make code organized, such as MailServiceProvider::registerMarkdownRenderer.