[BUG]: Cosmos proxy Mixed Content

[vncloudsco]

What happened?

The software does not have the ability to convert all http connections to https, We have tested many software and discovered that the system does not have the feature to switch all connections via https by default, leading to errors.

What should have happened?

Proxy apps Mixed Content

How to reproduce the bug?

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Relevant log output

No response

Other details

System details

• OS: ubuntu
• Browser chrome

[vncloudsco]

The error was due to my browser, I resolved it successfully

[saschatrebbin]

I have exactly this problem and would like to reopen this issue - but as a question. I want to host firefly III and have Cosmos as the reverse proxy in front of firefly III.

But I get the same error as @vncloudsco:

Mixed Content: The page at 'https://finanzen.apps.hivenet.xyz/register' was loaded over HTTPS, but requested an insecure stylesheet 'http://finanzen.apps.hivenet.xyz/v3-local/dist/css/adminlte.min.css?v=6.0.30'. This request has been blocked; the content must be served over HTTPS.

This then breaks the webapp, which looks like this:

This happens on several devices and several browsers. The screenshot is from a fresh flatpak install of Vivaldi.

According to the docs of firefly III I need to forward the used protocol scheme to the container, so the app responds correctly. For nginx the docs provide an example: proxy_set_header X-Forwarded-Proto $scheme;

My question is: how can I achieve something like that with Cosmos? I have taken down the container for now to not expose a half configured webapp to the world.

[vncloudsco]

Hello @saschatrebbin I checked the software you are installing and suspected this problem. I found the cause is because this installation did not provide the full environment variables. I created a merge to fix it

[saschatrebbin]

That would be this MR, correct?

The missing environment variable would then be this line: "APP_URL=https://{Hostnames.{StaticServiceName}.{StaticServiceName}.host}",

I forgot to mention that I do not use the ServApp, but I tested the fix with my docker compose file. Adding the APP_URL environment variable didn't change the behavior of my firefly iii instance. I also have not seen anything new in the container logs.

According to a comment in the official .env for firefly-iii file this is environment variable should not help in cases like this.

#
# If you have trouble configuring your Firefly III installation, DON'T BOTHER setting this variable.
# It won't work. It doesn't do ANYTHING. Don't believe the lies you read online. I'm not joking.
# This configuration value WILL NOT HELP.
#
# Notable exception to this rule is Synology, which, according to some users, will use APP_URL to rewrite stuff.
#
# This variable is ONLY used in some of the emails Firefly III sends around. Nowhere else.
# So when configuring anything WEB related this variable doesn't do anything. Nothing
#
# If you're stuck I understand you get desperate but look SOMEWHERE ELSE.
#
APP_URL=http://localhost

So in my test with a docker compose file the environment variable did exactly what the dev said - absolutely nothing web related. Can anyone confirm this?

[vncloudsco]

@saschatrebbin It's completely normal, please rest assured to use