Download the PHP package macromindonline/laravel-proxy without Composer

Laravel Trusted Proxies

Laravel 5.5

TrustedProxy is now included with Laravel 5.5. To configure for this version of Laravel, please see: https://laravel.com/docs/5.5/requests#configuring-trusted-proxies

Laravel 5.0 - 5.4

For Laravel versions 5.0 - 5.4, please continue below.

New features include:

1. TrustedProxies are now set as in an HTTP Middleware, which makes more logical sense than the previous ServiceProvider. If you're unsure what that means, remember to "Just Trust Fideloper™".
2. You can now set the trusted header names. This is useful for proxies that don't use the usual X-Forwarded-* headers. See issue #9 and issue #7 for an example and discussion of that.

To use this with Laravel 5, run the following from your Laravel 5 project directory:

Or of course, you can edit your composer.json file directly:

Laravel 4

You can still use this package for Version 4 of Laravel. See the latest v2 tag of this repository, which is compatible with version 4 of Laravel.

WAT

Setting a trusted proxy allows for correct URL generation, redirecting, session handling and logging in Laravel when behind a proxy.

This is useful if your web servers sit behind a load balancer, HTTP cache, or other intermediary (reverse) proxy.

TL;DR Setup:

Install Trusted Proxy:

Add the Service Provider:

Publish the package config file to config/trustedproxy.php:

Register the HTTP Middleware in file app/Http/Kernel.php:

Then edit the published configuration file config/trustedproxy.php as needed.

The below will trust a proxy, such as a load balancer or web cache, at IP address 192.168.10.10:

Note: If you're using AWS Elastic Load Balancing or Heroku, the FORWARDED and X_FORWARDED_HOST headers should be set to null as they are currently unsupported there.

What's All This Do?

If your site sits behind a load balancer, gateway cache or other "reverse proxy", each web request has the potential to appear to always come from that proxy, rather than the client actually making requests on your site.

To fix that, this package allows you to take advantage of Symfony's knowledge of proxies. See below for more explanation on the topic of "trusted proxies".

Slightly Longer Installation Instructions

Installation is typical of a Laravel 5 package:

1. Install the package
2. Add the Service Provider
3. Publish the configuration file
4. Add the Middleware
5. Configure your Trusted Proxies

Install the Package

This package lives inside of Packagist and is therefore easily installable via Composer:

Method One:

$ composer require fideloper/proxy

Method Two:

Once that's added, run $ composer update to download the files.

If you want to develop on this, you'll need the dev dependencies, which you can get by adding the --dev flag to the composer require command.

Add the Service Provider

The next step to installation is to add the Service Provider.

Edit config/app.php and add the provided Service Provider:

Publish the configuration file

This package expects the trustedproxy.php configuration file be available at /config/trustedproxy.php. You can do this by copying the package configuration file via the new Laravel 5 artisan command:

Once that's finished, there will be a new configuration file to edit at config/trustedproxy.php.

Register the middleware

Edit app/Http/Kernel.php and add the provided Middleware:

Configure Trusted Proxies

Edit the newly published config/trustedproxy.php:

In the example above, we are pretending we have a load balancer or other proxy which lives at 192.168.1.10.

Note: If you use Rackspace, Amazon AWS or other PaaS "cloud" services which provide load balancers, the IP address of the load balancer may not be known. This means that every IP address would need to be trusted.

*In that case, you can set the 'proxies' variable to '':**

Using * will tell Laravel to trust all IP addresses as a proxy.

However, if you are in the situation where, say, you have a Content Distribution Network (like Amazon CloudFront) that passes to load balancer (like Amazon ELB) then you may end up with a chain of unknown proxies forwarding from one to another. In that case, '*' above would only match the final proxy (the load balancer in this case) which means that calling $request->getClientIp() would return the IP address of the next proxy in line (in this case one of the Content Distribution Network ips) rather than the original client IP. To always get the original client IP, you need to trust all the proxies in the route to your request. You can do this by:

In that case, you can set the 'proxies' variable to '':**

Which will trust every single IP address.

Changing X-Forwarded-* Header Names

By default, the underlying Symfony Request class expects the following header names to be sent from a proxy:

• X-Forwarded-For
• X-Forwarded-Host
• X-Forwarded-Proto
• X-Forwarded-Port

Some proxies may send slightly different headers. In those cases, you can tell the Symfony Request class what those headers are named.

For example, HAProxy may send an X-Forwarded-Scheme header rather than X-Forwarded-Proto. We can adjust Laravel (Well Actually™, the Symfony HTTP Request class) to fix this with the following configuration:

And voilà, our application will now know what to do with the X-Forwarded-Scheme header.

Don't worry about the defaults being IN_THIS_FORMAT, while we set the headers In-This-Format. It all gets normalized under the hood. Symfony's HTTP classes are the bomb 💥.

Some services don't support specific headers, so you can also set these to null to untrust them. In particular, AWS ELB and Heroku don't support FORWARDED and X_FORWARDED_HOST so you should set these to null in order to prevent users from spoofing trusted IPs.

Do you even CIDR, brah?

Symfony will accept CIDR notation for configuring trusted proxies as well. This means you can set trusted proxies to address ranges such as 192.168.12.0/23.

Check that out here and here to see how that is implemented in Symfony.

Why Does This Matter?

If your site is behind a proxy such as a load balancer, your web application may have some of the following issues:

1. Redirects and PHP-generated URLs may be inaccurate in terms of its web address, protocol and/or port.
2. Unique sessions might not be created for each user, leading to possible access to incorrect accounts, or an inability for a user to log in at all
3. Logging or other data-collection processes data may appear to come from one location (the proxy itself) leaving you with no way to distinguish between traffic/actions taken by individual clients.

We can work around those issues by listening for the X-Forwarded-* headers. These headers are often added by proxies to let your web application know details about the originator of the request.

Common headers included are:

• X-Forwarded-For - The IP address of the client
• X-Forwarded-Host - The hostname used to access the site in the browser
• X-Forwarded-Proto - The schema/protocol (http/https) used by the client
• X-Forwarded-Port - The port used by the client (typically 80 or 443)

Laravel uses Symfony for handling Requests and Responses. These classes have the means to handle proxies. However, for security reasons, they must be informed of which proxies to "trust" before they will attempt to read the X-Forwarded-* headers.

Laravel does not have a simple configuration option for "trusting" proxies out of the box. This package simply provides one.

Proxies in Symfony and Laravel

In order for Laravel to check for the forwarded IP address, schema/protocol and port, we need tell Laravel the IP addresses of our proxies, so the application knows to "trust" them. If it finds the IP address received is a trusted IP, it will look for the X-Forwarded-* headers. Otherwise, it will ignore.

If we do not tell Laravel what the IP address of our proxy (or proxies) is, it will ignore it for security reasons.

IP Addresses by Service

This Wiki page has a list of popular services and their IP addresses of their servers, if available. Any updates or suggestions are welcome!