Stream & upload over intranet wifi when co-located with server

[Sheraff]

Works like a charm in localhost dev:

• upload music files to intranet IP
• stream music files from intranet IP

But when deployed:

Mixed Content: The page at 'https://[[DOMAIN_NAME]].com' was loaded over HTTPS, but requested an insecure resource 'http://192.168.0.13:3000/api/local/ping'. This request has been blocked; the content must be served over HTTPS.

[Sheraff]

For this to work, we need to have SSL enabled; for SSL we need certificates; for certificates, we need a domain name. So I'm creating a domain name that will resolve to a local IP. This will require an internet connection to work, but once the DNS is resolved once it might be cached in something (router, browser) and be available even when fully offline.

[Sheraff]

Alternatively, we can use self-signed certificates and forgo the internet DNS resolution. This requires connecting to a static intranet IP (server is already on a static IP) with a specific port (can I manage to configure Apache for exposing some other port than 3000?). This should be secure enough as long as I don't have a hacker on the wifi.

[Sheraff]

Alternatively, we can use self-signed certificates and forgo the internet DNS resolution. This requires connecting to a static intranet IP (server is already on a static IP) with a specific port (can I manage to configure Apache for exposing some other port than 3000?). This should be secure enough as long as I don't have a hacker on the wifi.

Nope. This is forbidden too now: self-signing could (?) work but we either need

• to "become a certifying authority", which in practice means creating some other type of certificate to be loaded directly into chrome

and / or

• to have a domain name to register on the certificate

Without these, we get a new error:

• in chrome

  ERR_CERT_COMMON_NAME_INVALID

• in curl

  SSL: no alternative certificate subject name matches target host name

[Sheraff]

https://stackoverflow.com/questions/76174598/mixing-request-origins-in-audio-stream-of-206-ranges-causes-playback-to-stop