[bug]: Mixed http:// and https:// content when web-UI is loaded over http://

[gStart9]

Prerequisites

• I have searched for existing issues that already report this problem.

Server Hardware

Pure

StartOS Version

0344

Client OS

Linux

Client OS Version

Debian

Browser

Firefox

Browser Version

117

Current Behavior

When one loads their StartOS web-UI via http://, all elements on the page are loaded from http:// EXCEPT for one request to **https://startoswebui/login is induced. The referrer policy on the page is "strict-origin-when-cross-origin" so if a browser is actually paying attention to that referrer policy, https://startoswebui/login will be blocked from being requested. This is actually good afaict because if a user is at http://startoswebui/, they may not have trusted their certificate yet and https://startoswebui/login should not be requested or it could result in loud certificate warnings.

This is an issue at both the .local and the .onion

Expected Behavior

I expect all requests induced by StartOS web-UI to use the same http:// or https:// scheme as the rest of the page.

Steps to Reproduce

1. Load the web-UI via http://startoswebui.local or .onion
2. See that https://startoswebui/login is requested via https and blocked by your browser's CORS policy

Anything else?

No response

[MattDHill]

Please do some more testing that includes http/https in the URL, and also sure no security exceptions have been made for that certificate.

Finally, how does this express itself to the user. What is the actual bug or problem?

[gStart9]

Unfortunately firefox hides the http:// part of any http:// URL. The way you can tell it was requested via http:// is the red slash through the lock icon. I've made no security exceptions for https://monthly-cages.local - I have its cert trusted in Debian's trust store.

• Loading https://monthly-cages.local results in no issues.
• http://monthly-cages.local and https://monthly-cages.local are considered two different origins and the request to https://monthly-cages.local/login is blocked.
• Loading the web-UI via http://monthlycagesreallylong.onion results in the same issues (a request to https://monthlycagesreallylong.onion/login is induced by the javascript but blocked by the Firefox's cors policy

Finally, there is seemingly no actual dysfunction. Logins still work. It's just a question of why it's actually happening. I don't think this request to https:// from http:// is intentional. I searched through the js but don't seem to be able to see what is actually inducing the browser to request http://monthly-cages.local/login