Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-27970

Images URI contains wrong protocol when HTTPS connection goes through Varnish

    Details

      Description

      If eZ Publish uses Varnish and additional node for processing SSL connections then images URI contains wrong protocol (http:// instead of https://).

      Environment configuration:

      1. Option 1 (same as customer configuration)
        • haproxy - process SSL connection, "unpacks" it and forward HTTP request to Varnish
        • Varnish - process HTTP request, deliver cached content or if MISS sends request backed
        • Apache2 - vhost for eZ Publish, configured for HTTP connections
      1. Option 2 (created for additional test)
        • Apache2 - vhost for processing HTTPS requests, listen on 443 port, has configured proxy to Varnish. "Unpacks" HTTPS request and forward it to Varnish.
        • Varnish - process HTTP request, deliver cached content or if MISS sends request backed
        • Apache2 - vhost for eZ Publish, configured for HTTP connections

      Steps to reproduce:

      1. Configure environment in accordance with instruction above
      2. Go to https://ip:port of your haproxy/Apache2 (SSL) node
        All images served by the new stack won't be loaded. If you take a look at page source, you can see that every image has URI starting with *http://*.
        Images served by legacy (if any) will be loaded normally because they have relative URIs.

      Additional information:

      1. IORepositoryResolver::getBaseUrl() - in this case returns URL with *http://*
        (https://github.com/ezsystems/ezpublish-kernel-ee/blob/v5.4.10/eZ/Bundle/EzPublishCoreBundle/Imagine/IORepositoryResolver.php#L162-L187). In general, this behavior is correct, because in fact there is HTTP request, but later it is "packed" back to HTTPS by haproxy.

        Activity

        Hide
        André Rømcke added a comment - - edited

        What is app.php adapted to do for proxies here besides setting our env variable `SYMFONY_TRUSTED_PROXIES`
        http://symfony.com/doc/current/request/load_balancer_reverse_proxy.html

        Is the issue reproducible also for generating absolute urls using plain Symfony?
        https://symfony.com/doc/current/routing.html#generating-absolute-urls

        Show
        André Rømcke added a comment - - edited What is app.php adapted to do for proxies here besides setting our env variable `SYMFONY_TRUSTED_PROXIES` http://symfony.com/doc/current/request/load_balancer_reverse_proxy.html Is the issue reproducible also for generating absolute urls using plain Symfony? https://symfony.com/doc/current/routing.html#generating-absolute-urls
        Hide
        Adam Wójs added a comment -

        Closing as invalid. 127.0.0.1 needs to be added to the list of trusted proxies framework.trusted_proxies, because subrequests don't get into consideration `X-Forwarded-*` headers.

        Show
        Adam Wójs added a comment - Closing as invalid. 127.0.0.1 needs to be added to the list of trusted proxies framework.trusted_proxies , because subrequests don't get into consideration `X-Forwarded-*` headers.

          People

          • Assignee:
            Unassigned
            Reporter:
            Kamil Madejski
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: