Part-DB-server
Part-DB-server copied to clipboard
Part-DB Docker container seems to ignore that it's behind a reverse proxy
Describe the bug
The Part-DB Docker container appears to be ignoring the fact that it's behind a reverse proxy. Upon attempts to set DEFAULT_URI
in the docker-compose environment variables:
environment:
DEFAULT_URI="https://supercoolpartsdb.com/"
Rather than being happy with the fact that it now knows what it's dealing with, instead it throws an Internal Server Error with nothing that useful to help me along (image in screenshots).
To make matters worse, removing the quotes around the URL still have the container trying to pull some assets (looks to be avatars, more than anything) from localhost.
To Reproduce Steps to reproduce the behavior:
- set the
DEFAULT_URI
env var to the desired URL indocker-compose.yml
-
docker-compose up -d
(as normal) - try to navigate to Part-DB behind the reverse proxy
- See the container being angry
Expected behavior Login page should pop up as normal, with assets being pulled externally
Screenshots
Server Side
- Part-DB Version: 1.9.1
- PHP Version: 8.1.26 (SAPI: fpm-fcgi)
- Database Server: SQLite
Desktop (please complete the following information):
- OS: Windows 11 Pro (also observed on macOS Sonoma)
- Browser: Google Chrome
- Version 119.0.6045.160 (macOS: 119.0.6045.159)
Additional context
The following was found when docker logs partdb
was ran:
- - 28/Nov/2023:08:51:13 +0000 "GET /index.php" 500
{"message":"Matched route \"parts_show_all\".","context":{"route":"parts_show_all","route_parameters":{"_route":"parts_show_all","_controller":"App\\Controller\\PartListsController::showAll","_locale":"en"},"request_uri":"http://localhost:8069/en/parts","method":"GET"},"level":200,"level_name":"INFO","channel":"request","datetime":"2023-11-28T08:51:14.009288+00:00","extra":{"token":null,"url":"/en/parts","ip":"172.28.0.1","http_method":"GET","server":"localhost","referrer":"https://supercoolpartsdb.com/en/login"}}
{"message":"Uncaught PHP Exception OneLogin\\Saml2\\Error: \"Invalid array settings: sp_acs_url_invalid, sp_sls_url_invalid\" at /var/www/html/vendor/onelogin/php-saml/src/Saml2/Settings.php line 141","context":{"exception":{"class":"OneLogin\\Saml2\\Error","message":"Invalid array settings: sp_acs_url_invalid, sp_sls_url_invalid","code":2,"file":"/var/www/html/vendor/onelogin/php-saml/src/Saml2/Settings.php:141","trace":["/var/www/html/vendor/onelogin/php-saml/src/Saml2/Auth.php:178","/var/www/html/vendor/nbgrp/onelogin-saml-bundle/src/Onelogin/AuthFactory.php:25","/var/www/html/var/cache/docker/ContainerSn1rxYt/getAuthRegistryInterfaceService.php:22","/var/www/html/var/cache/docker/ContainerSn1rxYt/App_KernelDockerContainer.php:228","/var/www/html/var/cache/docker/ContainerSn1rxYt/getSecurity_Authenticator_Saml_MainService.php:38","/var/www/html/var/cache/docker/ContainerSn1rxYt/App_KernelDockerContainer.php:228","/var/www/html/var/cache/docker/ContainerSn1rxYt/getSecurity_Authenticator_Manager_MainService
.php:30","/var/www/html/var/cache/docker/ContainerSn1rxYt/App_KernelDockerContainer.php:228","/var/www/html/var/cache/docker/ContainerSn1rxYt/getSecurity_Firewall_Authenticator_MainService.php:20","/var/www/html/var/cache/docker/ContainerSn1rxYt/App_KernelDockerContainer.php:228","/var/www/html/var/cache/docker/ContainerSn1rxYt/getSecurity_Firewall_Map_Context_MainService.php:40","/var/www/html/vendor/symfony/security-bundle/Security/LazyFirewallContext.php:48","/var/www/html/vendor/symfony/security-http/Firewall.php:128","/var/www/html/vendor/symfony/security-http/Firewall.php:95","/var/www/html/vendor/symfony/event-dispatcher/EventDispatcher.php:260","/var/www/html/vendor/symfony/event-dispatcher/EventDispatcher.php:220","/var/www/html/vendor/symfony/event-dispatcher/EventDispatcher.php:56","/var/www/html/vendor/symfony/http-kernel/HttpKernel.php:157","/var/www/html/vendor/symfony/http-kernel/HttpKernel.php:76","/var/www/html/vendor/symfony/http-kernel/Kernel.php:197","/var/www/html/vendor/symfony/runtime/
Runner/Symfony/HttpKernelRunner.php:35","/var/www/html/vendor/autoload_runtime.php:29","/var/www/html/public/index.php:5"]}},"level":500,"level_name":"CRITICAL","channel":"request","datetime":"2023-11-28T08:51:14.011546+00:00","extra":{"token":null,"url":"/en/parts","ip":"172.28.0.1","http_method":"GET","server":"localhost","referrer":"https://supercoolpartsdb.com/en/login"}}
172.28.0.1 - - [28/Nov/2023:08:51:14 +0000] "GET /en/parts HTTP/1.1" 500 4224 "https://supercoolpartsdb.com/en/login" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"
Hope this helps.
You need to remove the quotes around DEFAULT_URI. See issue #427
Besides the Default URI currently is not really required besides when you want to use SAML.
More important is configuring the right value for TRUSTED_PROXIES so the right IPs and locations can be determined:
https://docs.part-db.de/installation/reverse-proxy.html
Can confirm removal of the quotes has resolves the HTTP 500. However, I can't say the same about setting TRUSTED_PROXIES and the Part-DB Docker container continuing to point the browser to localhost
for avatar assets.
As it's a container, and that I'm honestly not sure what this is otherwise supposed to be, i've set TRUSTED_PROXIES=127.0.0.1
in my docker config, along with the DEFAULT_URI, but it's still not correcting properly.
I've got the following two lines in my Apache config:
ProxyPass / http://localhost:8069/ retry=0
ProxyPassReverse / http://localhost:8069/
Though something tells me I'm missing something. Any suggestions on this one?
Can confirm removal of the quotes has resolves the HTTP 500. However, I can't say the same about setting TRUSTED_PROXIES and the Part-DB Docker container continuing to point the browser to
localhost
for avatar assets.
Which assets exactly are not correctly loaded. The browser developer console, should show the 404 messages for the pathes
Sorry for the delayed reply, been meaning to get to this but completely forgot.
It appears Part-DB is trying to hit http://localhost:8069/media/cache/thumbnail_xs/img/default_avatar.png but is getting ERR_CONNECTION_REFUSED.
At the time of this writing, it looks like an update is available. Currently on 1.9.1, will try an upgrade and get back to you if this persists.
Upgraded to 1.10.0, issue persists.
This should be fixed with the latest commit from the master branch.
Hey there! Can confirm that's resolved with 0.10.1, thank you so much.
Looks like there's also some issues with pulling assets relating to product photos however:
localhost:8069/media/cache/resolve/thumbnail_sm/media/part/1/ryzen55600gboxed-6565718ee9342.jpg:1 GET https://localhost:8069/media/cache/resolve/thumbnail_sm/media/part/1/ryzen55600gboxed-6565718ee9342.jpg net::ERR_CONNECTION_REFUSED
I meant to bring this up earlier, but haven't had a chance to. I'm so sorry about this!
If you'd prefer a separate issue to be raised for this one, I'm more than happy to.
Just had a closer look at this, if it helps at all it looks like this is, at least on the surface, isolated to just the list views at the moment. Again, if would be better raised under its own issue, happy to move the convo there.
edit .env.local : and change APP_ENV from pro to env then symfony debuger will work and you can show what the wrong