This is only tangentially related, but I have a love-hate relationship with Immich. Love for everything, but loads of hate for the bug-o-feature that disallows sharing of albums if the website is not hosted over HTTPS.

I can fiddle with the page content in Developer Tools to make it work, but frankly, WTF, especially since Immich expects people to set up a reverse proxy for HTTPS access on their own and does not help them in any way (like providing a pre-configured caddy in their compose.yaml, I don't know)

▲ AussieWog93 2 days ago | parent [-]

Honestly, this is a problem that has been solved by LLMs. Just point Claude Code to the server over SSH and say "We need Immich to be served over HTTPS".

You could theoretically upstream the fixed compose.yaml if you felt like it, but the project seemed unusually hostile towards the one fix I tried to upstream.

▲ smw 2 days ago | parent [-]

Here's the entirety of the Caddy config to reverse proxy something with managed tls certs. I feel like it's not that big a deal?

  photos.example.com {
          reverse_proxy 127.0.0.1:8080 {
                  header_up X-Real-IP {remote_host}
          }
  }

▲ crtasm 2 days ago | parent | next [-]

caddy passes on the source IP by default so it's even easier than that

    photos.example.com {
        reverse_proxy 127.0.0.1:8080
    }

the immich documentation covers this as well as nginx, apache and traefik https://docs.immich.app/administration/reverse-proxy

	▲	sam_lowry_ 2 days ago \| parent [-]
		Heh... I self-host Immich with Caddy, and it's more complex, really. Caddy runs in podman, there are firewall rules to allow traffic in and out and proper dependencies in systemd units and a readme that covers all that. Exactly the point OP is making. All because we forced TLS on everyone instead of solving the JS injection problem in some other alternative way. Like... legal, maybe?

▲ 2 days ago | parent | prev [-]

[deleted]