this post was submitted on 11 Nov 2024
380 points (98.5% liked)

Selfhosted

40296 readers
221 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

Immich is an amazing piece of software, but because it holds such personal data I have only ever felt comfortable accessing it via VPN or mTLS. This meant that I could never share any photos, which had been really bugging me.

So I built a self-hosted app, Immich Public Proxy, which allows you to share individual files or full galleries to the public without ever exposing your Immich instance. This uses Immich's existing sharing functionality, so other than the initial configuration everything else is handled within Immich.

Why not just expose Immich publicly with Traefik / Caddy / etc?

To share from Immich, you need to allow public access to your /api/ path, which opens you up to potential vulnerabilities. It's up to you whether you are comfortable with that in your threat model.

This proxy provides a barrier of security between the public and Immich. It doesn’t forward traffic to Immich, it validates incoming requests and responds only to valid requests without needing privileged access to Immich.

Demo

You can see a live demo here, which is serving a gallery straight out of my own Immich instance.

Features

  • Supports sharing photos and videos.
  • Supports password-protected shares.
  • Creating and managing shares happens through Immich as normal, so there's no change to your workflow.

Install

Setup takes about 30 seconds:

  1. Take a copy of the docker-compose.yml file and change the address for your Immich instance.

  2. Start the container: docker-compose up -d

  3. Set the "External domain" in your Immich Server Settings to be whatever domain you use to publicly serve Immich Public Proxy. Now whenever you share an image or gallery through Immich, it will automatically create the correct public path for you.

For more detail on the steps, see the docs on Github.

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 17 points 1 week ago

Oh man, total flashback to when I did this for Owncloud https://github.com/Fmstrat/shorten

[–] [email protected] 14 points 1 week ago (2 children)

You can see [a live demo here](https://immich-demo.note.sx/share/ffSw63qnIYMtpmg0RNvOui0Dpio7BbxsObjvH8YZaobIjIAzl5n7zTX5d6EDHdOYEvo), which is serving a gallery straight out of my own Immich instance.

Sorry, off topic, but is this what Immich looks like out of the box, or have you used any other plugins?

Immich Public Proxy looks like exactly what I want for my family photos, but I haven't looked into Immich yet. The demo looks beautiful, and is simple enough for the grandparents to use 🙂

[–] [email protected] 14 points 1 week ago (1 children)

Sorry, off topic, but is this what Immich looks like out of the box, or have you used any other plugins?

No - this is using lightGallery. You can see what Immich looks like on their demo.

[–] [email protected] 6 points 1 week ago

Thank you 🙂

Immich on its own looks good, but if I set it up, I think I'll definitely install lightGallery to go with it 🙂

[–] [email protected] 4 points 1 week ago (1 children)

Not default but can highly reccommend immich its great.

[–] [email protected] 3 points 1 week ago

Thanks 🙂

[–] [email protected] 9 points 1 week ago (1 children)

Okay...I'm terribly confused by this project here, so maybe you can clarify some things.

First, looking through the code, it seems you're literally just taking input requests and replaying them to a target host. So if Immich is updated with changes that proxy doesn't have yet, everything breaks.

How is this adding more security than any other proxy?

[–] [email protected] 15 points 1 week ago* (last edited 1 week ago) (1 children)

You're correct - it is indeed taking input requests and requesting the related data from Immich.

How is this adding more security than any other proxy?

To allow sharing with Immich using a normal reverse proxy like Caddy or Traefik, you need to expose public access to the Immich /api/ path, along with a few other potentially dangerous paths. Any existing or future vulnerability has the potential to compromise your Immich instance.

This proxy is more secure as it does not allow public access to the Immich API path or to any Immich path. The only incoming requests which are honoured are requests like this:

https://your-proxy-url.com/share/ffSw63qnIYMtpmg0RNvOui0Dpio7BbxsObjvH8YZaobIjIAzl5n7zTX5d6EDHdOYEvo

If the shared link does not resolve to something that you have intentionally shared from Immich, it will return a 404.

if Immich is updated with changes that proxy doesn’t have yet, everything breaks.

The only thing which would break it is if Immich changed the format of a few select API endpoints. And if that ever happens it's a very easy fix.

[–] [email protected] 2 points 1 week ago (1 children)

Or you could similar just block those routes in whatever reverse proxy you'd use out in front of the server?

I don't run Immich myself, but just trying to understand the technical issues and this particular solution. Seems like they should have a public facing /shared route that doesn't require access to any others, so I see your point.

[–] [email protected] 11 points 1 week ago

Or you could similar just block those routes in whatever reverse proxy you’d use out in front of the server?

You can't. You need to allow public access to your Immich instance's /api/ path to use Immich's built-in sharing.

[–] [email protected] 8 points 1 week ago (3 children)

A simpler way to protect a private service with a reverse proxy is to only forward HTTP GET requests and only for specific paths.

It’s extremely difficult to attack a service with only GET requests.

The security of which URLS are accessible without authentication would be up to immich.

[–] [email protected] 9 points 1 week ago (2 children)

I don't know the Immich API, but I've seen several REST APIs that used the usual pattern of

GET /api/v1/user/<id> - read user
POST /api/v1/user/ - create user
...

but also allowed

GET /api/v1/user/<id> - read user
GET /api/v1/user/?action=create - create user
...
[–] [email protected] 5 points 1 week ago (1 children)

Yup, also some APIs use GET for everything. It's a pain. And it means that filtering by verb only helps if you're intimately familiar with the API. And even then, only if you keep up with changes as they happen. So really, only if you're developing the API yourself.

[–] [email protected] 4 points 1 week ago* (last edited 1 week ago) (1 children)

(another pet peeve of mine is "rest" APIs that use 200 response codes for everything)

[–] [email protected] 2 points 1 week ago (1 children)

Ahhhhh whyyyyy, you've got all of these standard response codes made for you, why would you blatantly ignore them like that?!

[–] [email protected] 1 points 1 week ago

The only one I think is reasonable is GraphQL. But that isn't rest, and HTTP is just one of the transport layers it supports.

For anything claiming to be RESTful, it's a crime.

[–] [email protected] 1 points 1 week ago

Yes, there are broken uses of the HTTP protocol verbs where filtering to GET won’t work.

[–] [email protected] 8 points 1 week ago* (last edited 1 week ago) (1 children)

The security of which URLS are accessible without authentication would be up to immich.

This is exactly the risk I'm wanting to mitigate. Immich is under heavy active development, and I want to abstract away from needing to worry whether the no-auth API URLs are safe to expose publicly.

At the end of the day I feel safer knowing that there is zero public access to any part of my Immich instance, which for me is what really matters.

[–] [email protected] 4 points 1 week ago (1 children)

Immich has a whole set of end-to-end automated tests to ensure they don't accidentally make public any URLs they went to be private:

https://github.com/immich-app/immich/tree/main/e2e/src/api/specs

As a popular open source project, that would be e glaring security hole.

Using this proxy puts the trust in a far less popular project with fewer eyeballs on it, and introduces new risks that the author's Github account is hacked or there's vulnerability in he supply chain of this docker container.

It's also not true that you "never need to touch it again" . It's based on Node whose security update expire every two years. New image should be built at least every two years to keep to update with the latest Node security updates, which have often been in their HTTP/HTTPS protocol implementations, so they affect a range of Node apps directly exposed to the internet.

[–] [email protected] 3 points 1 week ago* (last edited 1 week ago)

All good points, and Apple has some of the most skilled engineers in the world and The Fappening still happened.

It's not possible for me to audit everything that's happening security-wise in Immich, but I can fully understand what's happening in this small codebase to my own satisfaction. At the end of the day I feel safer knowing that there is no public access to any part of my Immich instance.

It’s also not true that you “never need to touch it again”

I meant that you don't need to use it to share photos, not that you never need to update your docker containers! 😱 Thanks, I have clarified that.

[–] [email protected] 3 points 1 week ago (1 children)

Interestingly the recent D-Link NAS security flaw uses GET.

[–] [email protected] 2 points 1 week ago

Good example. It’s true that an even a GET request not designed to mutate data might still fail to validate input, allowing a SQL injection attack or other attack that escalates to the privileges that the running app has.

[–] [email protected] 8 points 1 week ago* (last edited 1 week ago)

Thank you very much for the work. I pondered a few times how I could do that safely as I don't feel like hosting it that publicly.
I run Jellyfin publicly behind Authelia but there arent any personal files inside so if they breach it, it would give them only movies, music and tv shows...

[–] [email protected] 5 points 1 week ago

This is excellent! Thank you!

[–] lemmeBe 5 points 1 week ago* (last edited 1 week ago)

Great work! 😎 Starred.

[–] [email protected] 4 points 1 week ago (1 children)

Please Proton team port over this UI to drive.

[–] [email protected] 1 points 1 week ago (1 children)
[–] [email protected] 1 points 1 week ago

A lot more than that, especially the UX part.

[–] [email protected] 2 points 1 week ago (1 children)

Pretty cool!

Have you thought about whether this could also be used for limited write access? A common use-case for abusive image gallery services that you cannot ordinarily fulfil with Immich is shared albums where multiple people that e.g. attended the same event can collect pictures in without complex authentication (just a single shared secret or even just the link to the album).

[–] [email protected] 1 points 1 week ago

I'd love that, too. Immich has more fine grained user control on their timeline, though.

load more comments
view more: next ›