Logo error: Mixed Content: The page at 'https:....' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http:....png'. This request has been blocked; the content must be served over HTTPS

[strider27]

@ecomsilio

We are not using a self signed certificate but I tried your suggestion anyway. But after that change, I get an error 500 when I try to create an invoice. There is no preview anymore and nothing else.

Don’t think it’s an ssl issue in your case so no need to troubleshoot this, just revert.

@ecomsilio

What is the big difference between the pdf generation processes?
In my case snappdf still does not show the logo. But phantomjs and hosted_ninja work fine. So I am almost thinking of switching to either phantomjs or hosted_ninja.

SnapPDF runs on the same host (in your case inside the container I guess) as Invoiceninja, it takes the html generated by invoice ninja, opens it in an instance of headless (means no visual output to user) chromium browser, which renders the html and stores it as a PDF file. All this is done without any info/data leaving your server. Your problem is that the chromium browser instance that runs within your container, can’t access the url that has the image, from within that container, (it could be on a different port internally which is then forwarded to 443 externally etc)

In case of PhantomJS and Hosted, the generated html is forwarded to another server (phantomJS Cloud or InvoiceNinja) rendered there and a PDF file is returned to you.
The only difference is where the html is rendered and pdf is compiled, in this case on somebody else’s server. This is theoretically slower (especially for large files etc.)
It seems that that server can access the jpg from outside your host/container.

As you are in Germany this may also be an issue from the GDPR compliance perspective, as you are sending your clients data to a third party for processing. If you decide to go this route you would need to obtain GDPR policy statements from the data processor, make sure they are compliant, disclose that info to clients etc. etc. etc. (it’s a pain in the ass)

[strider27]

Had Another look at this:

@Access-InTech

The only docker I use is on UNRAID for personal use and rarely if ever stray past UI. Like docker for dummies, but will try to help.

Can you try figuring out what the IP of your app is within the docker network?

docker ps -a to get the container ID

docker ps | tail -n +2 | while read cid b; do echo -n "$cid\t"; docker inspect $cid | grep IPAddress | cut -d \" -f 4; done

Look for the ID from step 1 it should have the IP underneath.

Can you try changing config/hosts or /etc/hosts (whichever it is in docker) so crm.ecomsilio.de resolves to the docker network container IP (alternatively you can also try host LAN IP, or external IP.)

This seems to have helped the guy below:

Company Logo not display within invoice

[david]

So the curl issue would most likely be the same reason the app is not displaying the logo as it cannot reach itself to pull in the image.

Could this be a networking issue itself with Traefik?

[Access-InTech]

Here’s how the internal docker network is resolving the container names:

So I guess the loopback address has to be set to traefik, because that’s the service which is reachable “from the outside”?
Or has it to be set to app, because that’s the service where the headless Chrome is executed?

[strider27]

Well, the less hops it has to do the better/faster it would be.

I would try app first, if that doesn’t work try server, then traefik.

You may have to adjust the hosts files for the server container as well as I don’t know if snappdf is running under app or server. As mentioned not familiar with docker structure at all.

[david]

Just as a follow up, I’ve seen this pop up a few times, so I’ve reworked the logo retrieval from docker containers to inject the base64 version, so this should be resolved in the next release.

[ecomsilio]

Thanks David,

we will wait for the update and give it another try.

Thanks,
Gijs

[ecomsilio]

Hi @david,

I just updated to 5.5.0 and the logo is now instantly displayed. From my feeling, the whole application also got a bit faster.

Thank you for all you effort! Also big thanks to @strider27 and @hillel. And to my admin @Access-InTech for trying out all this stuff.

Thanks
Gijs

[david]

@ecomsilio

Thanks for the update, I am glad we resolved this. I think this solution is better than trying to get the containers resolving themselves.

Interesting to hear that the app feels faster, it may be the PHP 8.1 upgrade