4.4.0 Wrong schema shown in base tag when using ContaoCache

[ausi]

On an HTTPS site the <base> tag in the header shows an http:// URL.

I debugged it and found out that Environment::get('ssl') returns false.

The backtrace for the first call to Environment::ssl() is:

#0  Contao\Environment::ssl() called at [.../vendor/contao/core-bundle/src/Resources/contao/library/Contao/Environment.php:65]
#1  Contao\Environment::get() called at [.../vendor/contao/core-bundle/src/Resources/contao/library/Contao/Environment.php:367]
#2  Contao\Environment::url() called at [.../vendor/contao/core-bundle/src/Resources/contao/library/Contao/Environment.php:65]
#3  Contao\Environment::get() called at [.../vendor/contao/core-bundle/src/Resources/contao/library/Contao/Environment.php:495]
#4  Contao\Environment::base() called at [.../vendor/contao/core-bundle/src/Resources/contao/library/Contao/Environment.php:65]
#5  Contao\Environment::get() called at [.../vendor/contao/core-bundle/src/Resources/contao/pages/PageRegular.php:502]
#6  Contao\PageRegular->createTemplate() called at [.../vendor/contao/core-bundle/src/Resources/contao/pages/PageRegular.php:108]
#7  Contao\PageRegular->prepare() called at [.../vendor/contao/core-bundle/src/Resources/contao/pages/PageRegular.php:49]
#8  Contao\PageRegular->getResponse() called at [.../vendor/contao/core-bundle/src/Resources/contao/controllers/FrontendIndex.php:306]
#9  Contao\FrontendIndex->renderPage() called at [.../vendor/contao/core-bundle/src/Resources/contao/controllers/FrontendIndex.php:78]
#10 Contao\FrontendIndex->run() called at [.../vendor/contao/core-bundle/src/Controller/FrontendController.php:42]
#11 Contao\CoreBundle\Controller\FrontendController->indexAction()
#12 call_user_func_array() called at [.../vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:153]
#13 Symfony\Component\HttpKernel\HttpKernel->handleRaw() called at [.../vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:68]
#14 Symfony\Component\HttpKernel\HttpKernel->handle() called at [.../vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php:171]
#15 Symfony\Component\HttpKernel\Kernel->handle() called at [.../vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php:467]
#16 Symfony\Component\HttpKernel\HttpCache\HttpCache->forward() called at [.../vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/HttpCache/HttpCache.php:60]
#17 Symfony\Bundle\FrameworkBundle\HttpCache\HttpCache->forward() called at [.../vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php:421]
#18 Symfony\Component\HttpKernel\HttpCache\HttpCache->fetch() called at [.../vendor/contao/manager-bundle/src/HttpKernel/ContaoCache.php:48]
#19 Contao\ManagerBundle\HttpKernel\ContaoCache->fetch() called at [.../vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php:191]
#20 Symfony\Component\HttpKernel\HttpCache\HttpCache->handle() called at [.../vendor/friendsofsymfony/http-cache/src/SymfonyCache/EventDispatchingHttpCache.php:98]
#21 Contao\ManagerBundle\HttpKernel\ContaoCache->handle() called at [.../vendor/terminal42/header-replay-bundle/src/SymfonyCache/HeaderReplaySubscriber.php:85]
#22 Terminal42\HeaderReplay\SymfonyCache\HeaderReplaySubscriber->postHandle()
#23 call_user_func() called at [.../vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/EventDispatcher.php:212]
#24 Symfony\Component\EventDispatcher\EventDispatcher->doDispatch() called at [.../vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/EventDispatcher.php:44]
#25 Symfony\Component\EventDispatcher\EventDispatcher->dispatch() called at [.../vendor/friendsofsymfony/http-cache/src/SymfonyCache/EventDispatchingHttpCache.php:142]
#26 Contao\ManagerBundle\HttpKernel\ContaoCache->dispatch() called at [.../vendor/friendsofsymfony/http-cache/src/SymfonyCache/EventDispatchingHttpCache.php:100]
#27 Contao\ManagerBundle\HttpKernel\ContaoCache->handle() called at [.../web/app.php:30]

It looks like at this first call the current request returns false for ->isSecure() and the Environment class caches this result for all subsequent calls.

[leofeyer]

I wasn't able to reproduce this.

Did you add or change anything?

[ausi]

Did you add or change anything?

Not knowingly.

If no one else has this issue, we can close this for now I think.

[dibole]

We have the same problems in the backend after installing the Managed Edition 4.4.2 with Contao Manager 0.9. Another installation created with Composer does not show this bug. For more Details please have a look at our post in the user forum

[ausi]

@dibole Could you please try if the issue disappears if you remove the line $kernel = new ContaoCache($kernel); from the web/app.php file?

[dibole]

@ausi We have removed the line as you suggested, but unfortunately the issue does not disappear. Now it is even worse, because now the wrong base href with http appears also in the Contao Login screen.
In this screen it was always with the right base href https before!

[dibole]

After this we made a complete new installation in a new operating system (docker container) with Contao Manager Beta9, @leofeyer but the problem is still there and reproducable. Therefore I hope that this issue will be opened again.

[leofeyer]

How exactly can we reproduce the issue?

[dibole]

Heute haben wir bei der 4.4 Edition, die mit dem Composer installiert wurde, ein Update auf Version 4.4.2 gemacht und nun haben wir dort ebenfalls das Problem, dass die base href im HTML-Header im Backend nach dem Login auf eine unverschlüsselte Domain zeigt und deshalb die CSS-Files nicht geladen werden. Vor dem Login zeigt die base href übrigens noch auf die verschlüsselte Domain). Der Bug liegt also nicht am Contao Manager, sondern muss mit dem Update von 4.4 auf 4.4.2 reingekommen sein. @leofeyer Wir benutzen Apache (Events) und PHP-fpm

[dibole]

Neue Erkenntnis: Die in Contao verwendete Funktion isSecure von Symfony funktioniert bei der Verwendung eines Proxies nur, wenn diese mittels der Funktion setTrustedProxies definiert wurden -> http://api.symfony.com/2.3/Symfony/Component/HttpFoundation/Request.html#method_isSecure

[xgcssch]

dibole is right: setTrustedProxies solves the problem.
As i'm not familiar with the codebase, i added
Request::setTrustedProxies(array('192.168.1.2'));
to app.php.
192.168.1.2 is the upstream loadbalancer with ssl-decoding.
Best regards
Sönke

[Toflar]

As i'm not familiar with the codebase, i added
Request::setTrustedProxies(array('192.168.1.2'));

This is exactly the way to go. That's how you have to set trusted proxies in Symfony applications :)

[aschempp]

Just be aware that app.php is overwritten when you update a regular Contao Managed Edition.

[leofeyer]

Not ideal. Can this be configured or do we have to adjust our app.php file?

[Toflar]

You cannot configure that. It is by design that it has to go to your entry point. It used to be a configuration parameter in Symfony but it was deprecated and removed. So for a standard Symfony app, modifying it in app.php (or index.php for Symfony 4) is the way to go.
In the Contao Managed Edition we could provide a configuration parameter that itself then writes it into the entry points when generating them. I'd happily vote for accepting such a PR but no time to work on that because I don't need it myself atm.

[leofeyer]

@xgcssch Maybe you can copy the app.php file and store your changes under a different name (e.g. app_custom.php or even index.php). Then if you adjust the rewrite rules, your application will use your custom entry point, which is never overwritten.

[aschempp]

What do you think about adding an environment variable for trusted proxies, so we can set it through the .env file?

[leofeyer]

Not sure. Why does Symfony not have this option?