如何在负载均衡器 (ssl_termination) 后面使用 Laravel 5 配置 SSL？

How do I configure SSL with Laravel 5 behind a load balancer (ssl_termination)?

提问by maherio

I have a laravel 5 project deployed to AWS EC2 web instances, behind an ELB with ssl termination.

我有一个 Laravel 5 项目部署到 AWS EC2 Web 实例，位于带有 ssl 终止的 ELB 后面。

For things like assets, Laravel by default uses whatever scheme is currently used. However, I've noticed since the https traffic is decrypted by the ELB and forwarded to the EC2 nodes via http, Laravel does not think it's currently using https and thus uses http for assets. This is obviously causing problems.

对于资产之类的东西，Laravel 默认使用当前使用的任何方案。但是，我注意到由于 https 流量被 ELB 解密并通过 http 转发到 EC2 节点，Laravel 认为它当前没有使用 https，因此将 http 用于资产。这显然会引起问题。

From what I've found, Laravel checks for this sort of proxy setup using the X_FORWARDED_PROTO header. However I've found this header doesn't exist and instead there is an HTTP_X_FORWARDED_PROTO header. In researching this, I've found that prepending "HTTP_" is something php does. If that's true, then why isn't Laravel checking for it, as it is a purely php framework?

根据我的发现，Laravel 使用 X_FORWARDED_PROTO 标头检查此类代理设置。但是我发现这个标头不存在，而是有一个 HTTP_X_FORWARDED_PROTO 标头。在研究这个时，我发现在“HTTP_”前面加上 php 是这样做的。如果这是真的，那么为什么 Laravel 不检查它，因为它是一个纯粹的 php 框架？

I've read articles saying to use something like Fideloper's Trusted Proxies, yet it's unclear why Laravel doesn't check for these headers by default.

我读过一些文章说要使用Fideloper's Trusted Proxies 之类的东西，但不清楚为什么 Laravel 默认不检查这些标头。

How can I configure Laravel to accept HTTP_X_FORWARDED_* headers, or otherwise configure it to know my current scheme is https?

如何配置 Laravel 以接受 HTTP_X_FORWARDED_* 标头，或以其他方式配置它以了解我当前的方案是 https？

采纳答案by Alan Storm

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 mightlead to something being compromised.

默认情况下，Laravel 不会检查这些，因为这些标头可以简单地注入到请求中（即伪造），这会在您的应用程序中创建理论上的攻击向量。恶意用户可以让 Laravel 认为请求是安全的或不安全的，这反过来可能会导致某些内容受到损害。

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

当我几个月前使用 Laravel 4.2 遇到同样的问题时，我的解决方案是创建一个自定义请求类并告诉 Laravel 使用它

#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

然后在 中MyCustomReuqestClass，我扩展了基本请求类并添加了额外的 is/is-not 安全逻辑

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 classas a parent, meaning a Laravel request inherits a Symfony request object's behavior.

我现在不会这样做。使用框架几个月后，我意识到 Laravel 的请求类以Symfony 请求类为父类，这意味着 Laravel 请求继承了 Symfony 请求对象的行为。

That means you can tell Laravel which proxy servers it should trust with something like this

这意味着你可以通过这样的方式告诉 Laravel 它应该信任哪些代理服务器

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.

这段代码告诉 Laravel 它应该信任哪些代理服务器。之后，它应该选择标准的“转发给”标头。您可以在Symfony 文档中阅读有关此功能的更多信息。