I have a laravel 5 project deployed to AWS EC2 web instances, behind an ELB with ssl termination.
For things like assets, Laravel by default uses whatever scheme is curr
Laravel doesn't check for these by default because these headers can be trivially injected into a request (i.e. faked), and that creates a theoretical attack vector into your application. A malicious user can make Laravel think a request is, or is not secure, which in turn might lead to something being compromised.
When I ran into this same problem a few months back using Laravel 4.2, my solution was to create a custom request class and tell Laravel to use it her
#File: bootstrap/start.php
//for custom secure behavior -- laravel autoloader doesn't seem here yet?
require_once realpath(__DIR__) . 'path/to/my/MyCustomRequest.php';
Illuminate\Foundation\Application::requestClass('MyCustomRequest');
and then in MyCustomReuqestClass
, I extended the base request class and added extra is/is-not secure logic
class Request extends \Illuminate\Http\Request
{
/**
* Determine if the request is over HTTPS, or was sent over HTTPS
* via the load balancer
*
* @return bool
*/
public function secure()
{
$secure = parent::secure();
//extra custom logic to determine if something is, or is not, secure
//...
return $secure;
}
public function isSecure()
{
return $this->secure();
}
}
I would not do this now. After working with the framework for a few months, I realized that Laravel's request class has the Symfony request class as a parent, meaning a Laravel request inherits a Symfony request object's behavior.
That means you can tell Laravel which proxy servers it should trust with something like this
Request::setTrustedProxies(array(
'192.168.1.52' // IP address of your proxy server
));
This code tells Laravel which proxy servers it should trust. After that, it should pickup the standard "forwarded for" headers. You can read more about this functionality in the Symfony docs.